• Author / Uploaded
• Luis Sanchez Camacho

Citation preview

Universidad de Concepci´on Facultad de Ingenier´ıa Depto. de Ingenier´ıa El´ectrica

Apuntes de Redes de Datos 543483

Recopilador : Jorge E. Pezoa N´un˜ez : [email protected] Semestre : 2002-I Fecha : 11 de febrero de 2002

Tabla de Contenidos 1. Introducci´ on y Marco de Referencia

10

1.1. ¿Qu´e Son las Redes de Datos? ¿Para Qu´e Sirven? . . . . . . . . . . . . . . . .

10

1.2. Clasificaci´on de las Redes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.2.1. Clasificaci´on por Tecnolog´ıa de Transmisi´on . . . . . . . . . . . . . . .

10

1.2.2. Clasificaci´on por Escala . . . . . . . . . . . . . . . . . . . . . . . . . .

10

1.3. Modelos de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

1.3.1. El Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

1.3.2. El Modelo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

1.4. Protocolos, Interfaces, Servicios y Tipos de Servicios . . . . . . . . . . . . . . .

15

1.5. Ejemplos de una Red de Datos

. . . . . . . . . . . . . . . . . . . . . . . . . .

19

1.5.1. Ejemplo de LAN: Red del DIE . . . . . . . . . . . . . . . . . . . . . . .

19

1.5.2. Ejemplo de WAN: Red Reuna 2 . . . . . . . . . . . . . . . . . . . . . .

20

2. Protocolos LAN

23

2.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.2. Protocolos LAN y Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.3. Topolog´ıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4. El Medio F´ısico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4.1. Cable Coaxial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4.2. Par Trenzado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 2.4.3. Fibra Optica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.4.4. Enlaces de Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

2.4.5. Enlaces de Microondas . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

2.4.6. Infrarrojos y Ondas Milim´etricas . . . . . . . . . . . . . . . . . . . . .

30

2.4.7. Enlaces Satelitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.5. Capa de Enlace de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

2.5.1. Protocolos de Transmisi´on Confiable . . . . . . . . . . . . . . . . . . .

32

2.5.2. Protocolo Punto a Punto . . . . . . . . . . . . . . . . . . . . . . . . . .

38

2.5.3. El Problema de la Asignaci´on del Canal . . . . . . . . . . . . . . . . .

40

2.5.4. Protocolos de Acceso M´ ultiple Sin Detecci´on de Portadora . . . . . . .

41

2.5.5. Protocolos de Acceso M´ ultiple Con Detecci´on de Portadora . . . . . . .

42

2.5.6. Protocolos Libre de Colisiones . . . . . . . . . . . . . . . . . . . . . . .

44

2.5.7. Protocolos de Contenci´on Limitada . . . . . . . . . . . . . . . . . . . .

46

2

27

2.5.8. Protocolos Token Passing . . . . . . . . . . . . . . . . . . . . . . . . .

46

2.5.9. Protocolos de Redes Inal´ambricas . . . . . . . . . . . . . . . . . . . . .

48

2.6. Estandarizaci´on de Redes LAN . . . . . . . . . . . . . . . . . . . . . . . . . .

52

2.7. Tecnolog´ıas Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

2.7.1. Especificaci´on IEEE 802.3 y Ethernet . . . . . . . . . . . . . . . . . . .

54

2.7.2. Especificaci´on IEEE 802.3u Fast Ethernet . . . . . . . . . . . . . . . .

59

2.7.3. Gigabit Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

2.8. Token Bus/IEEE 802.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

2.9. Token Ring/IEEE 802.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

2.10. 100VGAnyLAN/IEEE 802.12 . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

2.11. FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

2.12. WLAN IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

2.13. Subcapa de Control de Enlace L´ogico . . . . . . . . . . . . . . . . . . . . . . .

82

2.14. Dispositivos LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

2.14.1. Repetidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

2.14.2. Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

2.14.3. Bridges

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

2.15. LAN Conmutadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

93

2.15.1. Store and Forward vs Cut-Through . . . . . . . . . . . . . . . . . . . .

95

2.15.2. LANs virtuales o VLANs . . . . . . . . . . . . . . . . . . . . . . . . . .

96

2.16. LAN Emulation: ATM y su Interconexi´on LAN . . . . . . . . . . . . . . . . . 102 3. Nivel de Red

108

3.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.2. Algoritmos de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.2.1. El Principio de Optimalidad . . . . . . . . . . . . . . . . . . . . . . . . 110 3.2.2. Ruteo por el Camino M´as Corto y M´etricas . . . . . . . . . . . . . . . 110 3.2.3. Ruteo Basado en el Flujo . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.2.4. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.2.5. Ruteo por Vector de Distancia . . . . . . . . . . . . . . . . . . . . . . . 112 3.2.6. Ruteo por Estado del Enlace . . . . . . . . . . . . . . . . . . . . . . . . 114 3.2.7. Ruteo Jer´arquico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.2.8. Ruteo Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.2.9. Ruteo Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

3

3.3. Algoritmos de Control de Congesti´on . . . . . . . . . . . . . . . . . . . . . . . 117 3.3.1. Principios Generales del Control de Congesti´on . . . . . . . . . . . . . 117 3.3.2. Factores que Influyen en la Congesti´on . . . . . . . . . . . . . . . . . . 118 3.3.3. Traffic Shaping y Traffic Policing . . . . . . . . . . . . . . . . . . . . . 119 3.3.4. Control de Admisi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 3.3.5. Choke Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.3.6. Descarte de Paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.4. El Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.4.1. Fragmentaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.4.2. Direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.4.3. Divisi´on en Subredes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 3.4.4. Classless Inter-Domain Routing: CIDR . . . . . . . . . . . . . . . . . . 135 3.4.5. Protocolos de Control IP . . . . . . . . . . . . . . . . . . . . . . . . . . 139 3.5. Conceptos de Ruteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.5.1. Sistema Aut´onomo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.5.2. Protocolos de Ruteo Interior . . . . . . . . . . . . . . . . . . . . . . . . 145 3.5.3. Protocolos de Ruteo Exterior . . . . . . . . . . . . . . . . . . . . . . . 157 3.6. Dispositivos de Nivel de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 3.6.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 3.6.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 3.7. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3.7.1. Direcciones en IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 3.7.2. Encabezado IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 3.8. IP Cl´asico sobre ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 4. Tecnolog´ıas WAN

177

4.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 4.1.1. Capa F´ısica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 4.1.2. Capa de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 4.1.3. Tipos de Redes WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 4.1.4. Internetworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 4.2. Tipos de Conexiones WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 4.2.1. Enlaces Punto-a-Punto . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 4.2.2. Conmutaci´on de Circuitos y de Paquetes . . . . . . . . . . . . . . . . . 180

4

4.2.3. Circuitos Virtuales WAN . . . . . . . . . . . . . . . . . . . . . . . . . . 181 4.3. Dispositivos WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 4.4. Servicios de Conexi´on WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 4.4.1. Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 4.4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 4.4.3. Acceso Remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 4.4.4. Servicios de Marcado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 4.4.5. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 4.4.6. Virtual Private Network (VPN) . . . . . . . . . . . . . . . . . . . . . . 188 5. Nivel de Transporte

190

5.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 5.1.1. Direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 5.1.2. Primitivas de Servicio de Transporte . . . . . . . . . . . . . . . . . . . 193 5.2. Elementos de Protocolos de Transporte . . . . . . . . . . . . . . . . . . . . . . 193 5.3. Protocolos TCP y UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.3.1. Protocolo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 5.3.2. Protocolo UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

5

´Indice de Figuras 1.

Clasificaci´on de las Redes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.

Comparaci´on Entre los Modelos OSI y TCP/IP . . . . . . . . . . . . . . . . .

14

3.

Flujo de Informaci´on en una Comunicaci´on . . . . . . . . . . . . . . . . . . . .

16

4.

Sucesivas encapsulaciones de datos en una red Ethernet . . . . . . . . . . . . .

17

5.

Ventajas de los esquemas de capas . . . . . . . . . . . . . . . . . . . . . . . . .

18

6.

Esquema L´ogico de la Red LAN del DIE. . . . . . . . . . . . . . . . . . . . . .

19

7.

Esquema a Nivel IP de la Red Reuna 2. . . . . . . . . . . . . . . . . . . . . . .

22

8.

Relaci´on Entre el Modelo OSI y los Protocolos LAN. . . . . . . . . . . . . . .

23

9.

Topolog´ıas T´ıpicas de una LAN . . . . . . . . . . . . . . . . . . . . . . . . . .

24

10.

Cable Coaxial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

11.

25

13.

Cable Par Trenzado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ Fibra Optica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ Modos de operaci´on de la Fibra Optica . . . . . . . . . . . . . . . . . . . . . .

14.

Protocolo Stop & Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

15.

Protocolo de Ventana Deslizante . . . . . . . . . . . . . . . . . . . . . . . . . .

36

16.

Estructura de un Frame PPP. . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

17.

Fases de la Negociaci´on PPP. . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

18.

Tiempos Involucrados en las Colisiones . . . . . . . . . . . . . . . . . . . . . .

42

19.

Estados de una Red CSMA/CD. . . . . . . . . . . . . . . . . . . . . . . . . . .

44

20.

El protocolo Bitmap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

21.

Operaci´on del protocolo Token Passing . . . . . . . . . . . . . . . . . . . . . .

47

22.

Red LAN Inal´ambrica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

23.

Formato de un frame Ethernet e IEEE 802.3 . . . . . . . . . . . . . . . . . . .

55

24.

Frame Ethernet Real. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

25.

Ubicaci´on de la Subcapa MII en el Modelo OSI. . . . . . . . . . . . . . . . . .

60

26.

Arquitectura Gigabit Ethernet. . . . . . . . . . . . . . . . . . . . . . . . . . .

63

27.

Organizaci´on F´ısica y L´ogica de una Red Token Bus. . . . . . . . . . . . . . .

64

28.

Formato del Frame Token Bus. . . . . . . . . . . . . . . . . . . . . . . . . . .

65

29.

Formato del Frame y Token de Token Ring . . . . . . . . . . . . . . . . . . . .

68

30.

Formato del Frame 100VGAnyLAN. . . . . . . . . . . . . . . . . . . . . . . . .

71

31.

Ejemplo de Operaci´on de una red 100VGAnyLAN. . . . . . . . . . . . . . . .

73

32.

Formato del Frame y Token FDDI . . . . . . . . . . . . . . . . . . . . . . . . .

75

12.

6

27 28

33.

Arquitectura del protocolo IEEE 802.11. . . . . . . . . . . . . . . . . . . . . .

76

34.

Componentes de la arquitectura IEEE 802.11. . . . . . . . . . . . . . . . . . .

76

35.

Transferencia en una WLAN y el NAV de uno de los nodos vecinos. . . . . . .

78

36.

Formato de un Frame de Datos IEEE 802.11.

. . . . . . . . . . . . . . . . . .

79

37.

Formato de los Frames de Control IEEE 802.11. . . . . . . . . . . . . . . . . .

82

38.

Formato de los Frames IEEE 802.3 LLC y SNAP . . . . . . . . . . . . . . . .

83

39.

Extensi´on de una LAN usando un repetidor . . . . . . . . . . . . . . . . . . .

85

40.

Extensi´on de una LAN usando bridges . . . . . . . . . . . . . . . . . . . . . .

89

41.

Loop formado por la conexi´on de LANs usando bridges . . . . . . . . . . . . .

90

42.

Equipos de Comunicaci´on LAN. . . . . . . . . . . . . . . . . . . . . . . . . . .

94

43.

Organizaci´on por piso para los cuatro grupos de trabajo. . . . . . . . . . . . .

97

44.

Organizaci´on usando m´ ultiples switches para los cuatro grupos de trabajo. . .

98

45.

Organizaci´on usando VLANs y enlaces Trunk para los grupos de trabajo . . . 100

46.

Arquitectura del Protocolo LANE. . . . . . . . . . . . . . . . . . . . . . . . . 103

47.

Interfases del Protocolo LANE. . . . . . . . . . . . . . . . . . . . . . . . . . . 105

48.

Conexiones de Control LANE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

49.

Conexiones de Datos LANE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

50.

El Problema de la Cuenta Hasta Infinito. . . . . . . . . . . . . . . . . . . . . . 113

51.

Ejemplo real de Traffic Shaping en una red ATM. . . . . . . . . . . . . . . . . 120

52.

Encabezado del Paquete IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

53.

Formato de las Direcciones IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

54.

Paquete IP Real. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

55.

Estructura de un paquete ARP IP para redes IEEE 802. . . . . . . . . . . . . 142

56.

Paquete ARP Real. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

57.

Estructura de un paquete a) RIP b) RIPv2. . . . . . . . . . . . . . . . . . . . 147

58.

Formato de un paquete RIP Real. . . . . . . . . . . . . . . . . . . . . . . . . . 149

59.

Descripci´on de los Tipos de Routers y Relaciones en OSPF.

60.

Estructura de un paquete OSPF. . . . . . . . . . . . . . . . . . . . . . . . . . 156

61.

Formato de un paquete OSPF Real. . . . . . . . . . . . . . . . . . . . . . . . . 158

62.

Estructura de un paquete de actualizaci´on EGP. . . . . . . . . . . . . . . . . . 160

63.

Estructura de un paquete BGP 3. . . . . . . . . . . . . . . . . . . . . . . . . . 164

64.

Equipos de Comunicaci´on de Nivel de Red. . . . . . . . . . . . . . . . . . . . . 167

65.

Encabezado del Paquete IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

66.

Encabezados Opcionales de un Paquete IPv6. . . . . . . . . . . . . . . . . . . 172 7

. . . . . . . . . . 154

67.

Ruteo A Trav´es de ATM con el Modelo Cl´asico. . . . . . . . . . . . . . . . . . 174

68.

Modo de Operaci´on de NHRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

69.

Tecnolog´ıas WAN y Su Relaci´on con las Capas OSI . . . . . . . . . . . . . . . 177

70.

Esquema de Enlace Punto a Punto WAN . . . . . . . . . . . . . . . . . . . . . 180

71.

Conexi´on WAN de Circuitos Conmutados . . . . . . . . . . . . . . . . . . . . . 181

72.

Conexi´on WAN de Paquetes Conmutados . . . . . . . . . . . . . . . . . . . . . 181

73.

Switches WAN Interconectando Routers . . . . . . . . . . . . . . . . . . . . . 182

74.

Conexi´on de M´ ultiples LANs a Nivel de Enlace. . . . . . . . . . . . . . . . . . 183

75.

Conexi´on de Nodos en LANs Remotas Usando Bridging. . . . . . . . . . . . . 184

76.

Conexi´on de M´ ultiples LANs a Nivel de Red. . . . . . . . . . . . . . . . . . . . 185

77.

Conexi´on de Nodos en LANs Remotas Usando Routing. . . . . . . . . . . . . . 185

78.

RAS Conectando M´ ultiples Clientes a una LAN. . . . . . . . . . . . . . . . . . 186

79.

Conexi´on VPN entre Cliente ISP y Router VPN de una Compa˜ n´ıa. . . . . . . 188

80.

Encabezado de un Segmento TCP. . . . . . . . . . . . . . . . . . . . . . . . . 202

81.

Esquema de un Segmento TCP Real. . . . . . . . . . . . . . . . . . . . . . . . 204

82.

Encabezado de un Datagrama UDP.

83.

Esquema de un Datagrama UDP Real. . . . . . . . . . . . . . . . . . . . . . . 207

. . . . . . . . . . . . . . . . . . . . . . . 206

8

´Indice de Tablas 1.

Grupos de Trabajo del Comit´e 802 de IEEE. . . . . . . . . . . . . . . . . . . .

53

2.

Medios F´ısicos m´as Utilizados Especificados en IEEE 802.3. . . . . . . . . . .

54

3.

Medios F´ısicos Especificados en IEEE 802.3u. . . . . . . . . . . . . . . . . . .

60

4.

Medios F´ısicos Especificados en IEEE 802.3z.

. . . . . . . . . . . . . . . . . .

62

5.

Resumen del uso de los campos de direcciones en un frame IEEE 802.11 . . . .

81

6.

Relaci´on entre los equipos de comunicaci´on LAN y los dominios de colisi´on y broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.

Denominaci´on de los tipos de nodos en diferentes redes . . . . . . . . . . . . . 108

8.

Algunos Valores y Significados del Campo Protocolo en un Paquete IP . . . . 126

9.

Valor de MTU Para Protocolos Comunes de Nivel de Enlace. . . . . . . . . . . 127

10.

Subredes y M´ascaras que Pueden Definirse en una Red Clase B. . . . . . . . . 136

11.

Subredes y M´ascaras que Pueden Definirse en una Red Clase C. . . . . . . . . 137

12.

Agrupaci´on de Redes Clase C en Superredes Asignadas Geogr´aficamente. . . . 138

13.

Algunos Puertos TCP/UDP Est´andar. . . . . . . . . . . . . . . . . . . . . . . 201

9

1.

Introducci´ on y Marco de Referencia

1.1.

¿Qu´ e Son las Redes de Datos? ¿Para Qu´ e Sirven?

Red de Datos: conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre s´ı, a trav´es de un medio en particular. Objetivos principales: 1. La informaci´on debe ser entregada de manera confiable y sin da˜ nos en los datos. 2. La informaci´on debe entregarse de manera consistente. 3. Los equipos que forman la red deben ser capaces de identificarse entre s´ı. 4. Debe existir una manera estandarizada de nombrar e identificar las partes de la red. Las redes, entre otras cosas, sirven para: Compartir recursos y ahorrar dinero. Aumentar la disponibilidad de la informaci´on. Permitir el acceso a informaci´on a una gran cantidad de usuarios (Internet).

1.2. 1.2.1.

Clasificaci´ on de las Redes Clasificaci´ on por Tecnolog´ıa de Transmisi´ on

Redes de Difusi´ on (Broadcasting): existe un s´olo canal o medio de comunicaci´on, que es compartido por todos los dispositivos de la red. Redes de Punto-a-Punto: consisten en m´ ultiples conexiones entre pares individuales de m´aquinas. 1.2.2.

Clasificaci´ on por Escala

LAN: son el punto de contacto de los usuarios finales. Su finalidad principal es la de intercambiar informaci´on entre grupos de trabajo y compartir recursos tales como impresoras y discos duros. Se caracterizan por tres factores: extensi´on (de unos cuantos metros hasta algunos kil´ometros), su tecnolog´ıa de transmisi´on (cable de par trenzado UTP o coaxial, fibra ´optica, portadoras con infrarojo o l´aser, radio y microondas en frecuencias no comerciales) y su topolog´ıa (anillo, bus u ´nico o doble, estrella, ´arbol y completas). Las velocidades en las LAN van desde los 10 Mbps hasta 622 Mbps. 10

Hub

Cable Coaxial a)

b)

Figura 1: Clasificaci´on de las Redes a) Broadcasting b) Punto a Punto

Los est´andares m´as comunes son el IEEE 802.3 llamado Ethernet y el IEEE 802.5 llamado Token Ring. Ethernet opera a 10 Mbps y sus extensiones operan a 100 Mbps (FastEthernet) y 1000 Mbps (GigabitEthernet). En este est´andar, todos los nodos escuchan todos los paquetes que circulan por la red, sacan una copia y examinan el destinatario. Si el destinatario es el nodo mismo, lo procesa y caso contrario, lo descarta para escuchar el siguiente. Para enviar un paquete sensa el medio para saber si est´a libre; de ser as´ı procede a enviar el dato. Si ocurre que dos nodos enviaron un paquete al mismo tiempo, se provoca una colisi´on y cada nodo vuelve a retransmitir su paquete despu´es de esperar un tiempo aleatorio. Token Ring opera entre 4 y 16 Mbps y utiliza un token o testigo, que permite , al nodo que lo posee, enviar paquetes a la red mientras los otros escuchan. Una vez que un nodo termina de enviar paquetes, pasa el token a otro nodo para que ´este transmita. MAN: corresponde es una versi´on m´as grande de una LAN en cuanto a topolog´ıa, protocolos y medios de transmisi´on, que por ejemplo puede cubrir un conjunto de oficinas corporativas o empresas en una ciudad. En general, cualquier red de datos, voz o video con una extensi´on de una a varias decenas de kil´ometros puede ser considerada una MAN. El est´andar IEEE 802.6 define un tipo de MAN llamado DQDB que usa dos cables half-duplex por los cuales se recibe y transmiten voz y datos entre un conjunto de nodos. Otra especificaci´on MAN (que es en realidad una especificaci´on WAN) corresponde a SMDS un tipo de conexi´on conmutada basada en switches que permite conectar LANs entre s´ı. Un aspecto t´ıpico de las MAN es que el medio f´ısico es de difusi´on, lo que simplifica el dise˜ no de la red. WAN: son redes que se expanden en una gran zona geogr´afica, por ejemplo, un pa´ıs o continente. Los beneficiarios de estas redes son los que se ubican en nodos finales que son

11

quienes corren aplicaciones de usuario. A la infraestructura que une los nodos de usuarios se le llama subred y abarca diversos aparatos de red (llamados routers o ruteadores) y l´ıneas de comunicaci´on que unen las diversas redes. Ejemplos de tecnolog´ıas WAN son Frame Relay y ATM, entre otras tecnolog´ıas de conmutaci´on de paquetes y de circuitos. En la mayor´ıa de las WAN se utilizan una gran variedad de medios de transmisi´on para cubrir grandes distancias. La transmisi´on puede efectuarse por microondas, por cable de cobre, fibra ´optica o alguna combinaci´on de los anteriores. Sin importar el medio, los datos en alg´ un punto se convierten e interpretan como una secuencia de unos y ceros para formar frames de informaci´on, luego estos frames son ensamblados para formar paquetes y los paquetes a su vez construyen archivos o registros espec´ıficos de alguna aplicaci´on.

1.3. 1.3.1.

Modelos de Referencia El Modelo OSI

La ISO (http://www.iso.org) ha definido un modelo de 7 capas que describe c´omo se transfiere la informaci´on desde una aplicaci´on de software a trav´es del medio de transmisi´on hasta una aplicaci´on en otro elemento de la red. Capa F´ısica. La capa f´ısica tiene que ver con el env´ıo de bits en un medio f´ısico de transmisi´on y se asegura de ´estos se transmitan y reciban libres de errores. Tambi´en describe los el´ectricos y mec´anicos asociados con el medio y los conectores as´ı como los tiempos aprobados para enviar o recibir una se˜ nal. Tambi´en especifica si el medio permite la comunicaci´on simplex, half duplex o full duplex. Capa de Enlace. En esta capa se toman los bits que entrega la capa f´ısica y los agrupa en algunos cientos o miles de bits para formar los frames. En este nivel se realiza un chequeo de errores y si devuelven acknowledges al emisor. La Capa de Enlace es la encargada de detectar si un frame se pierde o da˜ na en el medio f´ısico. De ser ´este el caso, debe de retransmitirlo, aunque en ocasiones dicha operaci´on provoca que un mismo frame se duplique en el destino, loa que obliga a esta capa a detectar tal anomal´ıa y corregirla. En este nivel se decide c´omo accesar el medio f´ısico. Capa de Red. Se encarga de controlar la operaci´on de la subred. Su tarea principal es decidir c´omo hacer que los paquetes lleguen a su destino dados un origen y un destino en un

12

formato predefinido por un protocolo. Otra funci´on importante en este nivel es la resoluci´on de cuellos de botella. En estos casos se pueden tener varias rutas para dar salida a los paquetes y en base a algunos par´ametros de eficiencia o disponibilidad se eligen rutas din´amicas de salida. Capa de Transporte. La obligaci´on de la capa de transporte es tomar datos de la capa de sesi´on y asegurarse que dichos datos llegan a su destino. En ocasiones los datos que vienen de la capa de sesi´on exceden el tama˜ no m´aximo de transmisi´on ( Maximum Transmission Unit o MTU) de la interfaz de red, por lo cual es necesario partirlos y enviarlos en unidades m´as peque˜ nas, lo que origina la fragmentaci´on y ensamblado de paquetes cuyo control se realiza en esta capa. Otra funci´on en esta capa es la de multiplexar varias conexiones que tienen diferentes capacidades de transmisi´on para ofrecer una velocidad de transmisi´on adecuada a la capa de sesi´on. La u ´ltima labor importante de la capa de transporte es ofrecer un mecanismo que sirva para identificar y diferenciar las m´ ultiples conexiones existentes, as´ı como determinar en qu´e momento se inician y se terminan las conversaciones (esto es llamado control de flujo). Capa de Sesi´ on. Esta capa establece, administra y finaliza las sesiones de comunicaci´on entre las entidades de la capa de presentaci´on. Las sesiones de comunicaci´on constan de solicitudes y respuestas de servicio que se presentan entre aplicaciones ubicadas en diferentes dispositivos de red. Estas solicitudes y respuestas est´an coordinadas por protocolos implementados en esta capa. Otro servicio de este nivel es la sincronizaci´on y el establecimiento de puntos de chequeo. Por ejemplo, si se hace necesario transferir un archivo muy grande entre dos nodos que tienen una alta probabilidad de sufrir una ca´ıda, es l´ogico pensar que una transmisi´on ordinaria nunca terminar´ıa porque alg´ un interlocutor se caer´a y se perder´a la conexi´on. La soluci´on es que se establezcan cada pocos minutos un punto de chequeo de manera que si la conexi´on se rompe m´as tarde se pueda reiniciar a partir del punto de chequeo, lo cual ahorrar´a tiempo y permitir´a tarde o temprano la terminaci´on de la transferencia. Capa de Presentaci´ on. La capa de presentaci´on provee servicios que permiten transmitir datos con alguna sintaxis propia para las aplicaciones o para el nodo en que se est´a trabajando. Como existen computadores que interpretan sus bytes de una manera diferente que otras (Big Endian versus Little Endian), es en esta capa donde es posible convertir los datos a un formato independiente de los nodos que intervienen en la transmisi´on. 13

Capa de Aplicaci´ on. En esta capa se encuentran aplicaciones de red que permiten explotar los recursos de otros nodos. Dicha explotaci´on se hace, por ejemplo, a trav´es de emulaci´on de terminales que trabajan en un nodo remoto, interpretando una gran variedad de secuencias de caracteres de control que permiten desplegar en el terminal local los resultados, a´ un cuando ´estos sean gr´aficos. Una situaci´on similar se da cuando se transmiten archivos de un computador que almacena sus archivos en un formato dado a otro, que usa un formato distinto. Es posible que el programa de transferencia realice las conversiones necesarias de manera que el archivo puede usarse inmediatamente bajo alguna aplicaci´on.

Presentación

Enlace de Datos

bits

Físico

Hw

frames

Aplicaciones Enlace

Sist. Op.

Red

Sw

paquetes

Fw

segmentos

Sesión Transporte

Usuario

Aplicación

Red Host a Red

Figura 2: Comparaci´on Entre los Modelos OSI y TCP/IP

1.3.2.

El Modelo TCP/IP

El Departamento de Defensa (DoD) de Estados Unidos defini´o un conjunto de reglas que establecieron c´omo conectar computadoras entre s´ı para lograr el intercambio de informaci´on, soportando incluso desastres mayores en la subred. Fue as´ı como se defini´o el conjunto de protocolos de TCP/IP. Para los a˜ nos 80 una gran cantidad de instituciones estaban interesados en conectarse a esta red que se expandi´o por todo EE.UU. El modelo TCP/IP consta solamente de 4 capas. Capa Host a Red. La capa inferior, se relaciona con la capa f´ısica respecto del modelo OSI, y contiene varios est´andares del Institute of Electrical and Electronics Engineers (IEEE, http://www.ieee.org/) como el 802.3 llamado Ethernet que establece las reglas para enviar datos por cable coaxial delgado (10Base2), cable coaxial grueso (10Base5), par trenzado (10Base-T), fibra ´optica (10Base-F) y su propio m´etodo de acceso al medio f´ısico. El 802.4 llamado Token Bus que puede usar estos mismos medios pero con un m´etodo de acceso diferente y otros est´andares denominados gen´ericamente como 802.X. 14

Capa de Red. Esta capa cumple, junto con la anterior, los niveles 1, 2 y 3 del modelo OSI. En este nivel se defini´o el protocolo IP cuya responsabilidad es entregar paquetes en los destinos indicados, realizando las operaciones apropiadas de ruteo y la soluci´on de problemas como congesti´on o ca´ıdas de enlaces. Capa de Transporte. Est´a formada por dos protocolos: TCP y UDP. El primero es un protocolo confiable y orientado a conexi´on, lo que significa que ofrece un medio libre de errores para enviar paquetes. El segundo es un protocolo no orientado a conexi´on y no es confiable. Capa de Aplicaci´ on. En la u ´ltima capa se encuentran decenas de aplicaciones ampliamente conocidas actualmente. Las m´as populares son los protocolos WWW, FTP, telnet, DNS, el servicio de correo electr´onico (SMTP), etc.

1.4.

Protocolos, Interfaces, Servicios y Tipos de Servicios

Protocolo de comunicaci´ on: es un conjunto de reglas que indican c´omo se debe llevar a cabo un intercambio de datos o informaci´on. Para que dos o m´as nodos en una red puedan intercambiar informaci´on es necesario que manejen el mismo conjunto de reglas, es decir, un mismo protocolo de comunicaciones. Interfaz: corresponde a la separaci´on o divisi´on entre dos capas de un modelo de comunicaci´on, y es la encargada de definir las operaciones b´asicas y los servicios que el nivel inferior ofrece a la capa superior del modelo. Servicios: son un conjunto de operaciones que un nivel provee al nivel superior. en otras palabras, define que operaciones puede ejecutar la capa, pero no especificar c´omo son implementadas estas operaciones. Entidades: son los elementos activos en cada nivel del modelo. Una entidad puede ser un software (un proceso) o hardware (un chip). Cada capa tiene un conjunto de operaciones que realizar y un conjunto de servicios que usa de otra capa. De esta manera, se identifica como usuario de servicio a la capa que solicita un servicio y como proveedor a quien la da. Cuando una entidad se comunica con otra ubicada en la misma capa pero en diferentes nodos se dice que se establece comunicaci´on entre entidades pares. Cada capa tiene un conjunto de servicio que ofrecer, el punto exacto donde se puede pedir el servicio se llama punto de acceso al servicio o SAP. En cada capa, la entidad activa recibe un bloque de datos consistente de un encabezado que tiene significado para el protocolo de esa 15

M H4

H2

H3

H4

M1

H3

H4

M1

M

T2

M

Protocolo Nivel 5 H4

Protocolo Nivel 4

H2

H3

M2 Protocolo Nivel 3

H3

H4

M1

H3

M2

H3

H4

M1

T2

H2

M

T2

H2

H3

M2

H3

M2

T2

Protocolo Nivel 2

Figura 3: Flujo de Informaci´on en una Comunicaci´on

capa y un cuerpo que contiene datos para ser procesados por esa entidad o que van dirigidos a otra capa. Las capas ofrecen servicios de dos tipos: orientadas a la conexi´ on y no orientadas a la conexi´ on. Adem´as, cada uno de estos servicios puede ser caracterizados por la cierta calidad de servicio que ofrecen. As´ı, se pueden tener servicios confiables y servicios no confiables. Servicios orientados a la conexi´ on. Es un tipo de servicio en el que obligatoriamente debe establecerse una conexi´on o camino, entre el origen y el destino antes de que cualquier dato pueda transmitirse. Los servicios orientados a conexi´on se caracterizan porque cumplen tres etapas en su tiempo de vida: negociaci´on del establecimiento de la conexi´on (etapa 1), sesi´on de intercambio de datos (etapa 2) y negociaci´on del fin de la conexi´on (etapa 3). Los servicios orientados a la conexi´on pueden ser considerados como “alambrados”, es decir, que existe un conexi´on alambrada entre los dos interlocutores durante el tiempo de vida de la conexi´on. Un ejemplo cl´asico de servicio orientado a la conexi´on es el tel´efono, pues se necesita establecer una conexi´on con el destinatario para que la comunicaci´on tenga efecto. Servicios no orientados a conexi´ on. Los servicios no orientados a conexi´on carecen de las tres etapas antes descritas y en este caso, los interlocutores env´ıan todos paquetes de datos que componen una parte del di´alogo, por separado, pudiendo ´estos llegar a su destino en desorden y por diferentes rutas. Es responsabilidad del destinatario ensamblar los paquetes, pedir retransmisiones de paquetes que se da˜ naron y darle coherencia al flujo recibido. Un ejemplo cl´asico para este tipo de servicio orientado es el correo (tradicional y electr´onico), pues en este caso no se necesita establecer una conexi´on con el destinatario para que la comunicaci´on tenga efecto, ya que el mensaje (carta o correo electr´onico) quedar´a en un sitio (casa, casilla de correos tradicional o casilla de correos electr´onica) del destinatario, quien al 16

a)

b)

c)

d)

Figura 4: Sucesivas encapsulaciones de datos en una red Ethernet a) de Nivel 2: Ethernet b) de Nivel 3: IP c) de Nivel 4: TCP d) de Nivel 5: POP

leer el mensaje producir´a el efecto de comunicaci´on. Servicio confiable. Un servicio es confiable si ofrece una transmisi´on de datos libre de errores. Para cumplir este requisito, el protocolo debe incluir mecanismos para detectar y/o corregir errores. La correcci´on de errores puede hacerse con informaci´on que est´a incluida en un paquete da˜ nado o pidiendo su retransmisi´on al interlocutor. Tambi´en es com´ un que incluya mecanismos para enviar acuses de recibo cuando los paquetes llegan correctamente.

17

Servicio no confiable. Un servicio es no confiable si el protocolo no asegura que la transmisi´on est´a libre de errores y es responsabilidad del protocolo de una capa superior (o de la aplicaci´on) la detecci´on y correcci´on de errores si esto es pertinente o estad´ısticamente justificable. A un servicio que es a la vez no orientado a la conexi´on y no confiable se le conoce como servicio de datagramas. Un servicio que es no orientado a la conexi´on pero que incluye acuse de recibo se conoce como servicio de datagramas con acuse de recibo. Un tercer tipo de servicio se le llama con solicitud de respuesta si consiste de un servicio no orientado a conexi´on y por cada env´ıo de datos se espera una respuesta inmediata antes de enviar el siguiente bloque de datos. En la Figura 4 se observa el proceso de encapsulaci´on de datos en una situaci´on real. Las im´agenes corresponden a un frame Ethernet capturado con el sniffer

1

Ethereal

(http://www.ethereal.com/), cuando un cliente est´a intentando leer su correo electr´onico. En la ventana superior se observa el frame completo capturado, en la Figura 4a) se observa s´olo la parte de la encapsulaci´on de nivel 2, es decir, los encabezados Ethernet que se le agregar al frame. A este nivel se agrega tambi´en un terminador, el que corresponde, como se ver´a m´as adelante, a un c´odigo de detecci´on de errores, motivo por el cual no es presentado. La Figura 4b) muestra la encapsulaci´on a nivel 3, en este caso protocolo IP. La Figura 4c) ense˜ na el nivel siguiente, en este caso la encapsulaci´on es TCP. Finalmente, la Figura 4d) muestra el u ´ltimo nivel, el de aplicaci´on, con el protocolo POP en acci´on enviando el nombre de usuario. Mail

HTTP

FTP

TCP

POP UDP

IP Ethernet

Token Ring

ATM

PPP

Coaxial

UTP

Fibra Óptica

Par Teléfono

Host A

Host B

Host C

Host D

Figura 5: Ventajas de los esquemas de capas

Las principales ventajas, adem´as de simplificar el estudio y desarrollo de protocolos, de un esquema de capas es su modularidad. Es decir, esto permite que en cada capa existan 1

Un sniffer es un programa o un dispositivo que permite capturar todo el tr´afico que est´a pasando por una

interfaz de red.

18

diversas opciones, lo que permite llegar con un mismo tipo de aplicaci´on a distintos clientes independiente de los protocolos intermedios utilizados. Esto, debido a que cada protocolo desarrolla un conjunto de funciones conocidas, hacia el nivel superior, y todas las alternativas (protocolos de un mismo nivel) desarrollan esas mismas funciones, por lo tanto, la elecci´on de un protocolo en un nivel es independiente de los protocolos usados en otros niveles. Un ejemplo de esta situaci´on se observa en la Figura 5 donde, en este caso particular, el protocolos de nivel 3 es u ´nico, en cambio en los otros niveles existen diversas alternativas, lo que permite a cualquiera de los hosts (A, conectado a una LAN Ethernet, B a una Token Ring, C a una red ATM y D un cliente conmutado telef´onico) accesar cualquiera de los protocolos de nivel 5.

1.5. 1.5.1.

Ejemplos de una Red de Datos Ejemplo de LAN: Red del DIE Subred 152.74.21.0

Internet

Subred 152.74.20.0 Switch

Firewall

Hub

Subred 152.74.22.0 Hub

Switch Router UdeC

Switch Router FI

Switch

Firewall

Hub

Subred 152.74.23.0 Switch

Figura 6: Esquema L´ogico de la Red LAN del DIE.

El Departamento de Ingenier´ıa El´ectrica de la Universidad de Concepci´on (http://www.die.udec.cl) consta de una red de datos formada por cinco subredes l´ogicas, de las cuales cuatro est´an funcionando y la otra est´a reservada para su uso futuro y labores de investigaci´on. La subred 152.74.21.0, ubicada en el segundo piso del edificio Tecnol´ogico Mec´anico est´a generada a partir de un switch, del cual cuelgan hubs que son los encargados de distribuir los puntos de red a los distintos clientes. El cableado est´a trazado con UTP categor´ıa 5 principalmente, salvo por un par de laboratorios que, a partir de un hub, cablean su espacio utilizando coaxial delgado. En la subred 152.74.21.0 se encuentran los servidores de correo, web, ftp, DNS, etc. 19

adem´as de los computadores presentes en cada uno de los laboratorios existentes en el edificio. La velocidad de la red es 10 Mbps. La subred 152.74.22.0 es generada por un switch UTP 10BaseT, el que alimenta hubs de cable coaxial y de cable UTP que conectan una serie de clientes PCs. Al igual que en el caso de la otra subred, la conexi´on al router de salida est´a hecha usando fibra ´optica, y la subred se encuentra ubicada f´ısicamente en el segundo piso del mismo edificio. Las m´aquinas conectadas a esta subred son principalmente PCs y estaciones SUN SPARC. Ambos switches de cada subred est´an conectados por una de sus puertas a estaciones SUN SPARC que hacen de firewall protegiendo y filtrando el tr´afico de cada subred. La subred IP a la cual est´an conectados los firewalls es la subred 152.74.20.0 que conecta ambos equipos usando un hub que se conecta al switch/router principal de la Facultad de Ingenier´ıa a trav´es de fibra ´optica. La subred 152.74.23.0 est´a ubicada f´ısicamente en el edificio nuevo de la Facultad de Ingenier´ıa, y se genera a partir de un switch, que alimenta un hub y la serie de clientes PC que pertenecen a los profesores del departamento. El cableado de la red es estructurado, UTP categor´ıa 5, y la conexi´on del switch con el router es a trav´es del mismo tipo de cable. La velocidad de la red es de 10 y 100 Mbps. El ruteo es est´atico en el switch/router de la facultad para el caso de la red 152.74.23.0, mientras que se utiliza RIP en la subred 152.74.20.0 para que el switch/router principal aprenda la ubicaci´on de las redes 152.74.21.0 y 152.74.22.0. La ruta por defecto que siguen los equipos es aquella que permite llegar al switch/router central de la Universidad, que es el punto que conecta todas las redes del campus y adem´as concentra el acceso WAN desde las ´ sedes de las ciudades de Chill´an y Los Angeles usando enlaces de Frame Relay de 512 kbps. Finalmente, es este equipo quien est´a encargado de realizar la conexi´on de la Universidad con Internet. 1.5.2.

Ejemplo de WAN: Red Reuna 2

Reuna 2 (http://www.reuna2.cl), es una Red de Tecnolog´ıa ATM basada en una red de Transporte SDH. Est´a compuesta por un Backbone o troncal de una velocidad de 155 Mbps, cuyos nodos centrales est´an distribu´ıdos a lo largo del pa´ıs entre Arica y Puerto Montt. A esta troncal se conectan las Universidades miembros del Consorcio REUNA, mediante enlaces de fibra ´optica, cuyas velocidades de acceso son de 155 Mbps. La red opera de la siguiente forma cuando un cliente de la red trata de conectarse a otro punto: S´ı la direcci´on de red IP destino pertenece a las direcciones de red IP de Reuna, 20

entonces, por medio de un enlace dedicado, establecido hasta la Universidad destino, desde la Universidad origen, se debe dar paso a la transferencia de datos. Esto es llamado tr´afico nacional o Intranet. Si la direcci´on de red IP destino no pertenece a las direcciones de red IP de Reuna, entonces se debe utilizar otro enlace dedicado, que es exclusivo para cada universidad, hasta el router central, que encaminar´a la petici´on de conexi´on donde corresponda por el enlace internacional o hacia otro router, seg´ un sus tablas de rutas. Esto es llamado tr´afico internacional o Internet. El dise˜ no de la red contempla que para el tr´afico nacional o intranet se aplica un ancho de banda dedicado de 10 Mbps, y utiliza el protocolo de ruteo din´amico OSPF. La conectividad a Internet de cada Universidad est´a dada por un circuito dedicado exclusivo, cuyo ancho de banda es el contratado para salida Internacional con alg´ un proveedor de Internet (ISP). El ruteo en este circuito es est´atico, es decir, cada router de acceso tiene conFigurada la ruta por defecto hacia el router central por su circuito exclusivo y el router central tiene rutas est´aticas para llegar a cada red interna de las Universidades por el circuito que corresponda.

21

UTA

UNAP Area X

UANT

UCN Area Y

US

UAT Area Z

UV MCI USA UPA

UTFSM Area A

UCH R. Central UTEM

UMCE

Reuna

UMAG UTAL Area B

UBB

UDEC Area C

UFRO

ULAG

UACH Area D

Area 0

Figura 7: Esquema a Nivel IP de la Red Reuna 2. 22

2.

Protocolos LAN

2.1.

Introducci´ on

Una LAN es una red de datos de alta velocidad, tolerante a fallas, que cubre un ´area geogr´afica relativamente peque˜ na. Generalmente conectan estaciones de trabajo, impresoras, PCs, etc. permitiendo el acceso compartido a dispositivos y aplicaciones, intercambio de archivos, etc. Las redes LAN podemos dividirlas en: LAN tradicionales entre las que est´an los est´andares IEEE 802.3, IEEE 802.4 y IEEE 802.5. LAN r´apidas entre las que cuentan Fast Ethernet, 100VGAnyLAN, FDDI, ATM y Gigabit Ethernet. LAN inal´ambricas.

Protocolos LAN y Modelo OSI Subcapa LLC

Modelo OSI

Gigabit Ethernet

100VGAnyLAN

FDDI

Token Ring IEEE 802.5

Capa Física

100BaseT

Subcapa MAC

IEEE 802.2

IEEE 802.3

Capa de Enlace de Datos

Ethernet

2.2.

Especificación de LAN

Figura 8: Relaci´on Entre el Modelo OSI y los Protocolos LAN.

El t´ermino Ethernet se refiere a la familia de implementaciones LAN que incluyen tres categor´ıas Ethernet e IEEE 802.3, Ethernet a 100 Mbps y Ethernet a 1000 Mbps. De lo anterior se desprende que existe una diferencia entre Ethernet e IEEE 802.3, ya que el primero especifica las capas 1 y 2 del modelo OSI, en cambio, IEEE 802.3 especifica la capa f´ısica y la subcapa MAC no definiendo la subcapa LLC (est´andar IEEE 802.2), que es com´ un para IEEE 802.5, 100BaseT, etc. Estas diferencias se aprecian en la Figura 8. 23

2.3.

Topolog´ıas

Las topolog´ıas t´ıpicas de una LAN se pueden observar en la Figura 9. Las topolog´ıas mostradas son topolog´ıas f´ısicas, por lo que no necesariamente deben ser topolog´ıa l´ogicas de conexi´on. Por ejemplo, se tiene el caso de una red LAN Token Bus, donde su topolog´ıa f´ısica es un bus Figura 9a) pero l´ogicamente, los nodos se ordenan en forma de anillo para implementar el protocolo de transferencia.

a)

b)

d)

c)

´ Figura 9: Topolog´ıas T´ıpicas de una LAN. a) Bus b) Anillo c) Estrella d) Arbol.

2.4.

El Medio F´ısico

Los medios de transmisi´on m´as utilizados en una LAN son el cable coaxial grueso y delgado, par trenzado y fibra ´optica siendo estos dos u ´ltimos los m´as usados actualmente, debido a los est´andares de cableado estructurado ya la complexidad de mantenci´on del cable coaxial el cual ha dejado de ser usado en redes locales. Estos medios de transmisi´on son llamados guiados, a diferencia de los no guiados como los enlaces de radio, de microondas o satelitales. 2.4.1.

Cable Coaxial

Consiste en un cable conductor interno cil´ındrico separado de otro cable conductor externo por anillos aislantes o por un aislante macizo. Esto se recubre por otra capa aislante que es la funda del cable. Este medio f´ısico, es m´as caro que el par trenzado, pero se puede utilizar a 24

Figura 10: Cable Coaxial.

m´as larga distancia, con velocidades de transmisi´on superiores, menos interferencias y permite conectar m´as estaciones. Se suele utilizar para televisi´on, telefon´ıa a larga distancia, LAN, conexi´on de perif´ericos a corta distancia, etc. Se utiliza para transmitir se˜ nales anal´ogicas o digitales. Sus inconvenientes principales son: atenuaci´on, ruido t´ermico, ruido de intermodulaci´on. Para se˜ nales anal´ogicas, se necesita un amplificador cada pocos kil´ometros y para se˜ nales digitales un repetidor cada kil´ometro. 2.4.2.

Par Trenzado

Figura 11: Cable Par Trenzado.

Se trata de dos hilos de cobre aislados y trenzados entre s´ı, y envueltos por una cubierta protectora. Los hilos est´an trenzados para reducir las interferencias electromagn´eticas con respecto a los pares cercanos que se encuentran a su alrededor (dos pares paralelos constituyen una antena simple, en tanto que un par trenzado no). Se pueden utilizar tanto para transmisi´on anal´ogica como digital, y su ancho de banda depende de la secci´on de cobre utilizado y de la distancia que tenga que recorrer. Es el tipo de cableado m´as econ´omico y, por ejemplo, la mayor´ıa del cableado telef´onico es de este tipo. La velocidad de transmisi´on depende del tipo de cable par trenzado que se est´e utilizando, debido a esto, la EIA/TIA lo ha dividido en categor´ıas:

25

Categor´ıa 1. Hilo telef´onico trenzado de calidad de voz no adecuado para las transmisiones de datos. Las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 1 MHz. Categor´ıa 2. Cable de par trenzado sin apantallar. Las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 4 MHz. Categor´ıa 3. Velocidad de transmisi´on t´ıpica de uso es de 10 Mbps en Ethernet. Con este tipo de cables se implementa las redes Ethernet 10BaseT. Las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 16 MHz. Categor´ıa 4. La velocidad de transmisi´on llega a 20 Mbps. Las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 20 MHz. Categor´ıa 5. Puede transmitir datos hasta 100 Mbps, y es la categor´ıa m´ınima utilizada en las implementaciones actuales de redes de datos. Las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 100 MHz. Categor´ıa 5e. es una mejora a la categor´ıa anterior, puede transmitir datos hasta 1 Gbps, y las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 100 MHz. Categor´ıa 6. es una mejora a la categor´ıa 5e, puede transmitir datos hasta 1 Gbps, y las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 250 MHz. Categor´ıa 7. es una mejora a la categor´ıa anterior, puede transmitir datos hasta 1 Gbps, y las caracter´ısticas de transmisi´on del medio est´an especificadas hasta una frecuencia superior de 600 MHz. El par trenzado, a pesar de tener una longitud m´axima limitada y de algunos aspectos negativos que presenta, es de hecho, la opci´on m´as usada y debe tenerse en cuenta debido a que ya se encuentra instalado en muchos edificios como cable telef´onico y esto permite utilizarlo sin necesidad de cambiar el cableado. Adem´as, resulta f´acil de combinar con otros tipos de cables para la extensi´on de redes. Existen dos tipos de pares trenzados, los apantallados o STP y los sin apantallar o UTP. Los pares sin apantallar son los m´as baratos aunque menos resistentes a interferencias. A velocidades de transmisi´on bajas, los pares apantallados son menos susceptibles a interferencias, 26

aunque son m´as caros y m´as dif´ıciles de instalar. En redes Ethernet el cable par trenzado a utilizar utiliza 4 pares. El STP combina varias t´ecnicas para reducir los problemas: apantallamiento, cancelaci´on y trenzado de los cables. Cada par es envuelto por una cubierta met´alica y adem´as, los cuatro pares son cubiertos por otra funda met´alica. Su impedancia t´ıpica es de 150 Ω. al usarse en redes de datos, permite reducir el ruido dentro y fuera del cable (crosstalk y EMI). Una complicaci´on adicional de este tipo de cable es que la cubierta met´alica necesita ser aterrizada. El UTP consiste en 4 pares trenzados una cierta cantidad de veces por metro, al igual que el STP, y son pr´acticamente iguales, salvo por las cubiertas met´alicas que tiene el STP y que est´an ausentes en UTP. Esto diferencia hace ser a UTP m´as econ´omico, menos costoso en mantenci´on y m´as f´acil de manejar. Existe tambi´en un h´ıbrido entre el UTP y el STP, llamado ScTP (Screened Twisted Pair) que es b´asicamente un cable UTP que tiene una cubierta met´alica que cubre los cuatro pares. Al igual que las cubiertas met´alicas del STP, ´esta debe ser adecuadamente aterrizada. La impedancia t´ıpica de un ScTP es de 100 ´o 120 Ω. 2.4.3.

´ Fibra Optica

´ Figura 12: Fibra Optica.

Se trata de un medio muy flexible y muy fino que conduce energ´ıa de naturaleza ´optica. Su forma es cil´ındrica con tres secciones radiales: n´ ucleo, revestimiento y cubierta. El n´ ucleo est´a formado por una o varias fibras muy finas de cristal o pl´astico. Cada fibra est´a rodeada por su propio revestimiento que es un cristal o pl´astico con diferentes propiedades ´opticas distintas a las del n´ ucleo . Alrededor de esto est´a la cubierta, constituida de material pl´astico o similar, que se encarga de aislar el contenido de aplastamientos, abrasiones, humedad, etc. Sus beneficios frente a cables coaxiales y pares trenzados son: Permite mayor ancho de banda. Menor tama˜ no y peso. 27

Menor atenuaci´on. Aislamiento electromagn´etico. Mayor separaci´on entre repetidores. Su rango de frecuencias es todo el espectro visible y parte del infrarrojo. El m´etodo de transmisi´on es el siguiente: los rayos de luz inciden con una gama de ´angulos diferentes posibles en el n´ ucleo del cable, entonces s´olo una gama de ´angulos conseguir´an reflejarse en la capa que recubre el n´ ucleo. Son precisamente esos rayos que inciden en un cierto rango de ´angulos los que ir´an rebotando a lo largo del cable hasta llegar a su destino. A este tipo de propagaci´on se le llama multimodal (Figura 13b)). Si se reduce el radio del n´ ucleo, el rango de ´angulos disminuye hasta que s´olo sea posible la transmisi´on de un rayo, el rayo axial, y a este m´etodo de transmisi´on se le llama monomodal (Figura 13a)).

a)

b)

c)

´ Figura 13: Modos de operaci´on de la Fibra Optica a) Monomodo b) Multimodo c) de ´Indice Gradual

Los inconvenientes del modo multimodal es que debido a que dependiendo al ´angulo de incidencia de los rayos, estos tomar´an caminos diferentes y tardar´an m´as o menos tiempo en llegar al destino, con lo que se puede producir una distorsi´on (rayos que salen antes pueden llegar despu´es). Debido a esto, se limita la velocidad de transmisi´on posible. Existe un tercer modo de transmisi´on que es un paso intermedio entre los anteriormente comentados y que consiste en cambiar el ´ındice de refracci´on del n´ ucleo. A este modo se le llama multimodo de ´ındice gradual (Figura 13c)). Los emisores de luz utilizados son: LED (de bajo costo, con utilizaci´on en un amplio rango de temperaturas y con larga vida media) e ILD (m´as caro, pero m´as eficaz y permite una mayor velocidad de transmisi´on).

28

2.4.4.

Enlaces de Radio

Las ondas de radio tienen como principales caracter´ısticas que son f´aciles generar, pueden viajar distancias largas, y penetran edificios f´acilmente. Adem´as, son omnidireccionales, lo que significa que ellas viajan en todas las direcciones desde la fuente, para que el transmisor y receptor no tengan que estar f´ısicamente alineados con cuidado. El rango de frecuencias utilizado por los enlaces de radio est´a entre 1 KHz y los 100 MHz) Las propiedades de ondas son dependientes de la frecuencia. A frecuencias bajas, atraviesan bien obst´aculos, pero el poder baja grandemente cuando se aleja de la fuente. A frecuencias altas, las ondas tienden a viajar en l´ıneas rectas y rebotar cuando consiguen obst´aculos. Ellas tambi´en son absorbidas por la lluvia. A cualquier frecuencia, las ondas est´an sujetas a interferencia de los motores y otros equipos el´ectricos. El problema principal que se presenta al usar estas bandas para comunicaci´on de datos es el ancho de banda relativamente bajo que ellas ofrecen (unos 300 bps). Debido a la habilidad de radio de viajar grandes distancias, la interferencia entre los usuarios es un problema. Por esta raz´on, todos los gobiernos licencian al usuario de transmisores de radio. 2.4.5.

Enlaces de Microondas

Por encima de los 100 MHz, las ondas viajan en l´ıneas rectas y pueden por consiguiente enfocarse estrechamente. Concentrando toda la energ´ıa en una haz peque˜ no usando una antena parab´olica se obtiene una raz´on se˜ nal a ruido bastante alta, permitiendo la comunicaci´on, pero las antenas transmisoras y receptoras deben alinearse con precisi´on entre s´ı. Adem´as, esta direccionalidad permite que m´ ultiples transmisores sean alineados seguidamente para comunicarse con m´ ultiples receptores seguidos sin interferencia. Puesto que las microondas viajan en una l´ınea recta, si las torres est´an demasiado separadas, la Tierra estar´a en el camino (recordar la curvatura del palneta). Por consiguiente, se necesitan repetidoras peri´odicamente. Mientras m´as altas sean las torres, m´as distantes pueden estar. La distancia entre las repetidoras sube muy bruscamente con la ra´ız cuadrada de la altura de la torre. Para torres con altura de 100 metros, las repetidoras pueden estar separadas entre s´ı unos 80 kms. Este hecho las hace ser relativamente baratas. A diferencia de las ondas a bajas frecuencias, las microondas no atraviesan bien edificios. M´as a´ un, aunque el haz pueda enfocarse bien al transmisor, hay todav´ıa alguna divergencia en el espacio. Algunas ondas pueden refractarse por capas atmosf´ericas bajas y pueden tomar 29

ligeramente m´as tiempo en llegar que las ondas directas. Las ondas retrasadas pueden llegar fuera de fase con la onda directa y por lo tanto cancelar la se˜ nal. La comunicaci´on por microondas se usa ampliamente para la comunicaci´on de tel´efono a larga distancia, tel´efonos celulares y distribuci´on de la televisi´on. En este tipo de enlaces puede llegar a transmitirse a velocidades de hasta 10 Mbps. 2.4.6.

Infrarrojos y Ondas Milim´ etricas

Estos medios de transmisi´on son ampliamente usados en la comunicaci´on de corto rango, por ejemplo, controles remotos de televisores, VCRs, etc. Son relativamente direccionales, baratos, y f´aciles de construir, pero su mayor inconveniente es que no atraviesan objetos s´olidos. Por otro lado, el hecho que las ondas infrarrojas no atraviesen paredes s´olidas tambi´en es una ventaja. Significa que un sistema infrarrojo en un cuarto de un edificio no interferir´a con un sistema similar en oficinas adyacentes. Adem´as, la seguridad de sistemas infrarrojos contra escuchar detr´as de las puertas es mejor que el de sistemas de radio precisamente por esta raz´on. Por esto, ninguna licencia gubernamental se necesita para operar un sistema infrarrojo, en contraste con sistemas de radio que deben ser autorizados. Estas propiedades han hecho del infrarrojo un candidato interesante para LANs inal´ambricas interiores. Por ejemplo, pueden equiparse computadores y oficinas en un edificio con transmisores y receptores infrarrojos sin necesidad de enfocar. Existen especificaciones para transmitir datos a 2 y 11 Mbps. 2.4.7.

Enlaces Satelitales

Un sat´elite de comunicaci´on puede ser pensado como un repetidor de microondas en el cielo. Contiene diversos transponders, cada uno de los cuales escucha alguna porci´on del espectro, amplifica la se˜ nal entrante, y hace una difusi´on de vuelta en otra frecuencia para evitar interferencia con la se˜ nal que entra. Los rayos que bajan son anchos o angostos, pudiendo cubrir grandes o peque˜ nas superficies de la tierra, respectivamente. Los enlaces satelitales se diferencian de los enlaces punto a punto terrestres en que los retardos producto de las distancia involucradas son considerables, t´ıpicamente 270 mseg. Esto es bastante en comparaci´on con los 3 µseg/km de los enlaces de microondas y los 5 µseg/km del coaxial o la fibra. Otra diferencia es que los sat´elites son por naturaleza elementos de difusi´on, lo que es u ´til en algunos casos, pero en otros, como la seguridad, no lo es. Otras caracter´ısticas son que el costo de una transmisi´on es independiente de la distancia y que

30

tienen una tasa de error baj´ısima. Como ejemplo del ancho de banda de un enlace satelital se puede comentar que un canal puede ser de unos 50 Mbps, con lo cual se pueden generar f´acilmente unos 800 subcanales de 64 Kbps.

2.5.

Capa de Enlace de Datos

El objetivo principal de esta capa son los m´etodos para la comunicaci´on confiable y eficiente entre dos m´aquinas adyacentes. Los problemas t´ıpicos que debe resolver son: los errores en los circuitos de comunicaci´on, sus velocidades finitas de transmisi´on y el tiempo de propagaci´on. Adem´as debe proveer cuatro servicios principales a la capa de red. A saber: 1. Transferencia de Datos: la funci´on principal del nivel es transferir los datos del nivel de red desde la fuente hasta el nivel de red del destino. Para esto, genera servicios no orientados a la conexi´ on sin acuse de recibo, donde la m´aquina fuente env´ıa frames al destino sin necesidad de saber si esta los recibi´o. Es apropiado si la frecuencia de errores del canal es muy baja o si el tr´afico es de tiempo real. Otro servicio un poco m´as confiable es el no orientado a la conexi´ on con acuse de recibo donde tampoco se requiere una conexi´on preestablecida, pero donde cada frame debe ser chequeado como recibo por el receptor. Este servicio es ideal en medios de transmisi´on no confiables como los inal´ambricos. El servicio m´as confiable de implementar es el orientado a la conexi´ on con acuse de recibo donde se debe establecer una conexi´on previo a la trasmisi´on de datos. Cada frame en este servicio es numerado y enviado al destino, donde llegan en el mismo orden de env´ıo y luego son acusados como recibidos. 2. Creaci´ on de Frames: la capa de enlace recibe de la f´ısica un flujo de bits, que puede o no estar libre de errores. Para asegurar un servicio libre de errores la capa crea frames, que son simplemente una cierta cantidad de bits recibidos desde el nivel inferior que incluyen un checksum y que tienen una cierta interpretaci´on u ´til. La generaci´on de frames presenta un gran problema de sincronismo, ¿d´onde empieza y d´onde termina un frame?. Una forma de solucionar esto es mediante la cuenta de caracteres donde existe un campo que indica la cantidad de caracteres que contiene el frame. Esta forma presenta serios problemas si se corrompe el valor del campo que indica la cantidad de caracteres. Una forma alternativa de soluci´on es utilizar caracteres de inicio y t´ermino como los caracteres ASCII DTE STX y DTE ETX, que indican el inicio y fin del texto transmitido. Otra alternativa, que resulta ser una mejora a la anterior es el bit stuffing, 31

donde se utilizan patrones de bits que son las marcas de inicio y fin del mensaje, y si por alg´ un motivo los datos presentan dentro de s´ı el pattern de marca, este es modificado agregando un bit que le receptor sabe de antemano que debe remover. La u ´ltima forma de crear los frames es aplicable s´olo a medios f´ısicos que presentan redundancia, y consiste en crear violaciones en la codificaci´ on del c´odigo. 3. Control de Errores: en los servicios confiables es necesario proveer mecanismos que permitan retransmitir de alguna forma los frames que han llegado err´oneos. Para esto se utilizan acuses de recibo positivos (frame est´a OK) y negativos (frame lleg´o en mal estado y debe retransmitirse). Adem´as de los acuses de recibo deben utilizarse timers y n´ umeros de secuencia, pues puede darse el hecho de que se pierda alg´ un acuse, lo que generar´ıa que la transmisi´on de cuelgue, o bien que un frame llegue m´as de una vez en buen estado. 4. Control de Flujo: se relaciona con el hecho de c´omo regular el env´ıo de informaci´on desde el emisor al receptor, que no tienen igual capacidad de procesamiento de datos. Para esto existen protocolos que no dejan transmitir datos al emisor sin previa autorizaci´on del emisor. Detecci´ on y Correcci´ on de Errores Se han desarrollado dos estrategias fundamentales para el manejo de los errores que pueden presentarse en la transmisi´on de datos. Una de ellas consiste en agregar informaci´on redundante en cada bloque de datos enviado, para que el receptor pueda deducir cu´al fue el caracter que se envi´o. La otra estrategia consiste en incluir redundancia para que el receptor pueda detectar la existencia de un error y solicitar una retransmisi´on. En el primer caso se utilizan c´ odigos correctores de error y en el segundo caso c´odigos detectores de errores. Los m´etodos m´as usados en la detecci´on y correcci´on de errores son: chequeo de redundancia c´ıclica, bits de paridad, c´odigo de Hamming y los algoritmos de Checksum. 2.5.1.

Protocolos de Transmisi´ on Confiable

Un frame es una estructura que contiene varios campos: el tipo de frame, n´ umero de secuencia (seq), n´ umero de acuse de recibo (ack) y naturalmente el paquete recibido o enviado a la capa de red. Tambi´en una serie de rutinas que permiten la detecci´on de acontecimientos varios o el establecimiento de tiempos de expiraci´on para determinadas situaciones de espera. Dado que en algunos casos interesa asociar un n´ umero de orden a cada frame, se contempla 32

una variable k que se va a utilizar para identificar cada frame, hasta el valor m´aximo MAXPKT a partir del cual se empieza otra vez desde cero. Los llamados protocolos ARQ son aquellos en que se espera confirmaci´on para cada dato enviado. Se suelen distinguir dos tipos de ARQ, el RQ “ocioso” (iddle RQ), que corresponde a los protocolos stop and wait, o de ventana deslizante de un bit, y el RQ continuo (continuous RQ) que se utiliza en los protocolos de ventana deslizante de m´as de un bit. 0 ACK ACK

ACK

1

Timeout

K AC

reTX

ACK

ACK

a)

ACK D-1 Timeout

reTX ¿descartar?

ACK

D-0

1 0

1 K AC

D-1

ACK D-0

ACK

ACK

b)

0

1 0

¡descartar!

tiempo

c)

Figura 14: Protocolo Stop & Wait a) Ideal b) con Timeout c) con Timeout y Numeraci´on

Protocolos Elementales 1. Protocolo simplex no restringido Se supone una comunicaci´on perfecta, sin errores, donde el receptor est´a siempre disponible y preparado para recibir frames con un espacio de buffer infinito, por lo que no debe efectuarse control de flujo. El emisor est´a siempre preparado para transmitir cualquier cosa que reciba de la capa de red. En este caso el u ´nico evento posible es llegada de un frame. 2. Protocolo simplex stop and wait En un caso m´as real, puede suceder que el receptor no siempre est´a disponible para recibir, por tener ocupado su buffer de entrada debido a que la capa de enlace no sea capaz de procesar los frames con suficiente rapidez o porque la capa de red del receptor no sea lo bastante r´apida. En este caso, lo m´as sencillo es que el emisor espere una confirmaci´on despu´es de enviar cada frame, de forma que s´olo despu´es de recibir la confirmaci´on env´ıe el siguiente. De esta manera 33

se garantiza la no saturaci´on del receptor. Esto es lo que se conoce como un protocolo stop and wait. (Figura 14a)) 3. Protocolo simplex para un canal con ruido Si el canal de comunicaci´on no es perfecto, los frames pueden alterarse debido al ruido de la comunicaci´on, o incluso perderse por completo. Gracias a la presencia del campo CRC el receptor podr´a detectar la llegada de un frame defectuoso, en cuyo caso pedir´a retransmisi´on. La posibilidad de que un frame se pierda por completo introduce una complicaci´on adicional, ya que si esto le ocurre por ejemplo a un ack el emisor pasado un tiempo razonable (Figura 14b)) enviar´a el frame de nuevo pensando que no ha llegado la primera vez, lo cual producir´ıa un frame duplicado que el receptor pasar´ıa a la capa de red, situaci´on inaceptable para cualquier protocolo. Para poder reconocer cuando un frame llega duplicado lo m´as sencillo es numerarlo, en este caso, el emisor no enviar´a un frame hasta recibir el acuse de recibo del anterior, por lo que bastar´ıa con numerarlos con un s´olo bit (Figura 14c)). Los protocolos donde el emisor espera una confirmaci´on o acuse de recibo para cada dato enviado se denominan protocolos Positive Acknowledgement with Retransmission (PAR) o Automatic Repeat reQuest (ARQ). En este protocolo el receptor no realiza la comprobaci´on del campo CRC, para ´el todo frame que reciba de la capa f´ısica es correcto y se supone que ´estos pueden llegar o perderse, pero no llegar de forma parcial o alterados. Se puede considerar que hay un nivel inferior que se ocupa de comprobar el CRC, y que descarta el frame en caso de detectar cualquier error. De esta forma el efecto ser´ıa equivalente a la suposici´on simplista de que los frames o no llegan o llegan perfectamente. Protocolos Full D´ uplex 1. Protocolo con piggybacking Los protocolos vistos transmiten datos en una sola direcci´on, y el canal de retorno es utilizado u ´nicamente para enviar frames de acknowledge cuyo contenido es irrelevante. Si se tiene que transmitir datos en ambas direcciones podr´ıa utilizarse dos canales half d´ uplex con los protocolos anteriores, pero ser´ıa m´as eficiente utilizar el canal half d´ uplex ya existente para enviar, en cada sentido, frames de datos y de ack. Un campo kind permitir´ıa diferenciar unos de otras. Aun m´as eficiente, en vez de generar un frame ack de manera autom´atica cada vez que 34

se recibe algo, podr´ıa esperarse a enviarlo cuando haya informaci´on u ´til que enviar. En tal caso, el ack viajar´ıa “gratis” y se ahorrar´ıa el env´ıo de un frame. Esta t´ecnica se conoce como piggybacking o piggyback acknowledgement. Para “montar” el ack en un frame de datos es preciso que ´este llegue pronto, o de lo contrario el emisor reenviar´a el frame, lo que echar´ıa por tierra la idea. Como no es posible saber de antemano cuando va a llegar el siguiente paquete de la capa de red, generalmente se adopta una soluci´on salom´onica: se espera un determinado tiempo y si no llega ning´ un paquete en ese tiempo se genera un frame ack. 2. Protocolo full duplex con piggybacking En el protocolo anterior los frames se numeraban con un bit. La numeraci´on s´olo era utilizada en el receptor para verificar el frame recibido, no para informar al emisor a que frame se aplicaba el ack. Esto produce problemas en el caso de un receptor lento y un frame que se pierde. Si el receptor informa en el ack del frame de datos recibido, el problema de que el emisor tome un ack como correspondiente al paquete equivocado desaparece, el protocolo se hace m´as robusto ya que tanto emisor como receptor llevan control del frame recibida. Cada frame enviado contiene el n´ umero de secuencia correspondiente (seq), el n´ umero correspondiente al paquete reci´en recibido del otro lado (ack) y los datos a enviar. Para que el protocolo funcione correctamente es preciso convenir en que uno de los lados inicie la comunicaci´on, y el otro le siga. De lo contrario podr´ıa ocurrir que ambos lados iniciaran la comunicaci´on a la vez, y cada frame es enviado dos veces. Tambi´en se enviar´ıan duplicados en caso de tener los timers demasiado bajos, sin embargo, los duplicados ser´ıan correctamente detectados a partir de la informaci´on de secuencia y la informaci´on transmitida a la capa de red ser´ıa correcta Protocolos de Ventana Deslizante 1. Protocolo de Ventana Deslizante Corresponde al caso en que utiliza una ventana deslizante de m´as de un bit. Esto hace que se pueda enviar n elementos sin esperar confirmaci´on, permitiendo un tr´ansito de m´aximo n frames en el canal. (Figura 15a)). Simplemente se puede ver como una extensi´on del protocolo Stop & Wait. 2. Protocolo de Ventana Deslizante con Retroceso n Cuando se utiliza un protocolo de ventana deslizante de m´as de un bit el emisor no act´ ua

35

0 1 2 3 0 1

0

D-0

0

D-1

-0

K AC - 1 K C A -2 K AC

D-2 D-3 D-0

-3 K C A

D-1

1 2

1 2 3 0

3 0 1

2 3 0

0

D-0

0

D-1 D-2 D-3

D-0

AC AC

0 K-

CK NA

-2

D-2

D-3 D-0

a)

1

1 K-

2 KAC

1 2 3

3 ¡descartar! 0 ¡descartar! 2 3

b)

0 2 1 2

D-0

0

D-1

AC

D-2 D-3 D-0 D-2 D-1 D-2

AC

0 K-

1

1 K-

K-3 AC -2 CK NA 0 KAC 2 KAC

3 0

¡No descartar! ¡No descartar!

2 1

tiempo

c)

Figura 15: Protocolo de Ventana Deslizante a) Ideal b) de Retroceso n c) de Repetici´on Selectiva

de forma sincronizada con el receptor: cuando el receptor detecta un frame defectuoso hay varios frames posteriores ya en camino, que llegar´an de todas formas a ´el, a´ un cuando reporte el problema inmediatamente. Existen dos posibles estrategias a seguir en este caso, la primera es que el receptor ignore los frames (posteriores) recibidos a partir del err´oneo (inclusive) y solicite al emisor la retransmisi´on de todos los frames siguientes. Esta t´ecnica se denomina retroceso n (Figura 15b)) y corresponde a una ventana deslizante de tama˜ no uno en el receptor. En este caso, el receptor se asegura que los frames se procesar´an en secuencia, por lo que no tiene que reservar espacio en el buffer para m´as de un frame. De todas formas, el emisor deber´a almacenar en su buffer todos los frames que se encuentren dentro de la ventana (es decir, todos los frames en tr´ansito), ya que en cualquier momento el receptor puede solicitar la retransmisi´on de alguno de ellos. 3. Protocolo de Ventana Deslizante con repetici´ on selectiva La segunda opci´on para solucionar el problema de las retransmisiones consiste en que el receptor descarte el frame err´oneo y pida s´olo la retransmisi´on de ´este, aceptando los frames posteriores que hayan llegado correctamente. Esto se conoce como repetici´ on selectiva (Figura 15c)) y corresponde a una ventana deslizante mayor que 1 en el receptor (normalmente, es de igual tama˜ no que la ventana del emisor). En otras palabras, la repetici´on selectiva consiste en aprovechar aquellos frames correctos que lleguen despu´es del err´oneo, y pedir al emisor que retransmita los que presentaron problemas. La desventaja que presenta el m´etodo es que ahora el receptor ha de disponer de 36

espacio en el buffer para almacenar todos los frames de la ventana, ya que en caso de pedirse retransmisi´on tendr´a que intercalar en su sitio el frame retransmitido antes de pasar los siguientes a la capa de red, esto porque la capa de red debe recibir los paquetes estrictamente en orden. Entonces, se puede decir que su funcionamiento corresponde al de una ventana deslizante de igual tama˜ no en el emisor que en el receptor, lo que esto supone tener un buffer lo suficientemente grande para almacenar un n´ umero de frames igual al tama˜ no de ventana que se est´e utilizando. La posibilidad de una recepci´on no secuencial de frames plantea nuevos problemas. Por ejemplo, suponiendo que el emisor env´ıa los frames 0 a 6, los que son recibidos correctamente. Entonces el receptor realiza las siguientes acciones: los transmite a la capa de red, libera los buffers correspondientes avanza la ventana para poder recibir siete frames m´as, cuyos n´ umeros de secuencia podr´an ser 7,0,1,2,3,4,5 y env´ıa un ack para los frames 0 a 6 recibidas. Si el ack no llega al emisor, ´este supondr´a que ninguno de ellos ha llegado, por lo que reenviar´a los frames 0 a 6 de nuevo. De ´estos, los frames 0 a 5 se encuentran dentro de la ventana del receptor. En un procesamiento secuencial, el receptor no aceptar´ıa estos frames si no recibe antes el frame 7 pendiente, pero con retransmisi´on selectiva se aceptar´ıan y se pedir´ıa retransmisi´on del 7. Una vez recibido, ´este se pasar´ıa a la capa de red seguido de los frames 0 a 5 antes recibidos, que ser´ıan duplicados de los anteriores. En este caso el receptor pasar´a frames duplicadas al nivel de red. La soluci´on a este conflicto est´a en evitar que un mismo n´ umero de secuencia pueda aparecer en dos ventanas consecutivas. Por ejemplo, si el tama˜ no de ventana es de 7 el n´ umero de secuencia podr´ıa ser de 4 bits y la ventana del receptor ser´ıa 0-6, 7-13, 14-4, etc. El valor m´aximo de la ventana para un protocolo de repetici´on selectiva en el caso general ser´ıa (MAX SEQ+1)/2. Aunque el n´ umero de secuencia se ha duplicado respecto al caso anterior, el n´ umero de frames que hay que mantener en el buffer no necesita ser superior al tama˜ no de ventana, ya que este ser´a el n´ umero m´aximo de frames que habr´a que manejar en cualquier circunstancia. La t´ecnica de repetici´on selectiva da lugar a protocolos m´as complejos que la de retroceso n, y requiere mayor espacio de buffers en el receptor. Sin embargo, cuando las l´ıneas de transmisi´on tienen una tasa de errores elevada da un mejor rendimiento, ya que permite aprovechar todos los frames correctamente transmitidos.

37

2.5.2.

Protocolo Punto a Punto

PPP fue desarrollado por el Internet Engineering Task Force (IETF http://www.ietf.org/) en 1990 y est´a especificado en los RFC 1661, 1662 y 1663. PPP fue dise˜ nado para ser flexible, por ello incluye un protocolo especial, denominado LCP (Link Control Protocol), que se ocupa de negociar una serie de par´ametros en el momento de establecer la conexi´on con el sistema remoto. Delimit.

Dirección

Control

Protocolo

Datos

Checksum

Delimit.

1B

1B

1B

1ó2B

>=0 B

2ó4B

1B

Figura 16: Estructura de un Frame PPP.

La estructura de un frame PPP (ver Figura 16) se basa en el de HDLC, pero a diferencia de ´este, PPP es un protocolo orientado a car´acter, lo que implica que la longitud del frame ha de ser un n´ umero entero de bytes. En funci´on de las caracter´ısticas del medio f´ısico se aplica relleno de bits o relleno de bytes (por ejemplo para transmisi´on por medios as´ıncronos). La descripci´on de cada uno de los campos del frames es la siguiente: Delimitador. 1 Byte, el frame tiene siempre la secuencia 01111110 como delimitador. Direcci´ on. 1 Byte, este campo no se utiliza y siempre vale 11111111. Control. 1 Byte tiene por defecto el valor 00000011, que corresponde a un servicio no confiable y no orientado a conexi´on. De todas formas, en el momento de establecer la conexi´on LCP puede negociar una transmisi´on fiable. Direcci´ on. 2 Bytes, que por defecto, corresponden a la secuencia 1111111100000011, a menos que se negocie una transmisi´on confiable. Para no transmitir estos dos bytes de informaci´on in´ util en todos los frames, generalmente LCP negocia la supresi´on de estos dos bytes al inicio de la sesi´on (salvo que se pida transmisi´on fiable). Notar que no aparecen en la Figura 16. Protocolo. 1 ´o Bytes establece a que tipo de protocolo pertenece el paquete recibido de la capa de red. As´ı, PPP permite establecer una comunicaci´on multiprotocolo, es decir, puede utilizarse para transmitir paquetes pertenecientes a diferentes protocolos del nivel de red. Entre las posibilidades se encuentra IP, IPX, Appletalk, DECNET, OSI y otros. 38

Datos. De una longitud variable hasta un m´aximo que negocia LCP al establecer la conexi´on. Por defecto el tama˜ no m´aximo del frame es de 1500 bytes. Checksum. 2 Bytes, pero puede ser de 4 si se negocia. PPP puede utilizarse sobre medios f´ısicos muy diversos, por ejemplo, conexiones mediante m´odem, ISDN, l´ıneas dedicadas, o incluso por conexiones SONET/SDH de alta velocidad. 1

Establecer Falla

Muerta

Terminar 6

2

Validar

3

Falla

5

Red Abierta

4

Figura 17: Fases de la Negociaci´on PPP.

La negociaci´on entre dos LCPs puede dar lugar a que todos o s´olo algunos de los valores propuestos sean aceptados. El protocolo establece mecanismos que permiten a los LCPs dialogar para llegar a un consenso en caso de discrepancia. Existe otro componente de PPP que es el NCP (Network Control Protocol) que se encarga de negociar los par´ametros espec´ıficos para cada protocolo utilizado. Por ejemplo, en el caso de una conexi´on IP desde un usuario conectado v´ıa m´odem le asigna din´amicamente una direcci´on IP, lo que es u ´til cuando el n´ umero de direcciones IP disponibles es menor que el n´ umero de usuarios del servicio. Adem´as, LCP permite utilizar diversos protocolos de autentificaci´on, como CHAP, PAP, Kerberos, etc. Las fases de una conexi´on PPP (ver Figura 17) son las siguientes: 1. Cuando se detecta la portadora es porque se ha realizado una conexi´on a nivel de capa f´ısica y la conexi´on est´a en la fase Establecer. Hasta entonces la l´ınea estaba en reposo o Muerta, ya que no exist´ıa conexi´on. 2. Se negocian las opciones LPC y si se llega a un acuerdo se pasa a la fase de Validar que consiste en la verificaci´on de identidad del usuario. 3. Al entrar en la fase de Red se invoca al protocolo NCP apropiado para configurar la capa de red. 4. Una vez configurada se pasa a la fase Abierta, y comienza el transporte de datos. 39

5. Finalmente la conexi´on pasa a fase de Terminar cuando ya no existen m´as datos para transmitir y se desea liberar la conexi´on. 6. Una vez finalizada la conexi´on se pasa a la etapa de reposo o Muerta. 2.5.3.

El Problema de la Asignaci´ on del Canal

De acuerdo a la clasificaci´on tecnol´ogica de las redes ´estas pueden ser redes broadcast o redes formadas por enlaces punto a punto. En el caso de las punto a punto, la informaci´on se env´ıa a la m´aquina situada al otro lado del enlace, que est´a claramente identificada y el medio de transmisi´on normalmente est´a siempre disponible. Los protocolos de nivel de enlace vistos hasta ahora tienen estas suposiciones. En las redes broadcast existe una nueva dificultad. Como el canal es compartido, es necesario habilitar mecanismos que permitan a cada host utilizar el medio para enviar frames a la m´aquina destino. El hecho de compartir el canal generar´a conflictos o incluso p´erdida de frames en algunos casos, por lo que los protocolos deber´an establecer mecanismos adecuados para resolver estos conflictos y permitir que los nodos retransmitan los frames que no hayan podido ser enviadas correctamente. Debido a esta mayor complejidad es que en las redes broadcast se suele dividir la capa de enlace en dos subcapas: una inferior, que se ocupa de controlar la funci´on de acceso al medio de transmisi´on, denominada subcapa MAC y la superior, llamada subcapa de control de enlace l´ ogico o LLC que corresponde a las funciones de la capa de enlace comunes a todo tipo de redes. Existen dos soluciones principales para resolver la problem´atica de c´omo asignar el canal o medio f´ısico compartido a los nodos de la red, una es la asignaci´on est´atica del canal y la otra es la asignaci´ on din´amica. Las formas de asignaci´on est´atica m´as utilizadas son Multiplexaci´ on por Divisi´on de Frecuencias o FDM y Multiplexaci´ on por Divisi´on de Tiempo o TDM. La idea es repartir el canal entre las estaciones que lo requieren, y una vez asignado un ancho de banda o un slot de tiempo a una estaci´on ´esta lo tendr´a reservado para su uso mientras no lo libere, independientemente de que lo use o no. Estos m´etodos no son aplicables a las redes broadcast debido a que la naturaleza del tr´afico es impulsivo o de r´afagas, lo que hace que se pierdan las frecuencias o slots asignados cuando un host no desea transmitir, haciendo el rendimiento muy pobre cuando el n´ umero de estaciones es mucho menor que el n´ umero de asignaciones de frecuencia o tiempo. Por otro lado, si el n´ umero de hosts es mayor que el de asignaciones 40

habr´an estaciones que no podr´an transmitir ni recibir datos. La asignaci´on din´amica del canal consiste en reservar el medio para transmitir s´olo cuando sea necesario. Como el medio de comunicaci´on es u ´nico, las estrategias de competencia (llamadas tambi´en estrategias de contienda) para acceder a ´el son variadas y asumen la ocurrencia de colisiones, que corresponden a la transmisi´on simult´anea (o casi simult´anea) de dos o m´as frames, los que se traslapan y producen una se˜ nal distorsionada en el medio. De todas formas, cabe destacar que existen esquemas de este tipo que evitan las colisiones. Otras estrategias utilizan el tiempo continuo para transmitir, es decir, transmiten cuando lo necesitan, y otras usan slots de tiempo o transmiten por intervalos. Tambi´en existen m´etodos que introducen mejoras que permiten al adaptador de red detectar colisi´on y esperar un tiempo para retransmitir el frame. Los m´etodos que no detectan una colisi´on deben esperar la respuesta del receptor de si la transmisi´on fue exitosa o no para reenviar el frame si es necesario. En resumen, las reglas que especifican como se resuelve la situaci´on de accesar el medio compartido se llaman protocolos de acceso al medio. La asignaci´on est´atica tiene la desventaja de que se puede subutilizar el canal cuando las transmisiones son impulsivas o de r´afagas de datos. La asignaci´on din´amica se realiza s´olo cuando sea necesario transmitir, pero pueden ocurrir colisiones producto de la contienda por el canal y se necesita definir estrategias para llegar a un acuerdo entre los nodos en cuanto a la utilizaci´on del canal. 2.5.4.

Protocolos de Acceso M´ ultiple Sin Detecci´ on de Portadora

ALOHA En este protocolo, cuando un host desea transmitir, simplemente emite un frame, sin preocuparse en ning´ un momento del estado del canal. Una vez finalizado, queda en espera de recibir la confirmaci´on de que la informaci´on ha sido recibida correctamente por el destinatario, quien verifica esto usando el campo CRC del frame. Si pasado un tiempo no se recibe confirmaci´on, el emisor supone que ha ocurrido una colisi´on y espera un tiempo aleatorio y a continuaci´on reenv´ıa el frame. El problema principal del protocolo es que el env´ıo de frames por parte de los nodos se hace en forma ca´otica y basta que dos frames colisionen o se solapen solamente en un bit para que ambos sean in´ utiles y deban retransmitirse, puesto que los nodos s´olo se percatar´an del problema despu´es de haber terminado la transmisi´on. Por otro lado, el segundo frame podr´ıa colisionar con un tercero, y as´ı sucesivamente, de ah´ı que en una red ALOHA cuando el tr´afico crece las colisiones aumentan de manera no lineal y el rendimiento decae r´apidamente. El rendimiento m´aximo de ALOHA es de 18,4 %, que se consigue con una utilizaci´on del canal del 50 %. 41

Colisión

Colisión

Colisión

A

A

B

B

C

C

t

a)

t

Colisión

b)

Figura 18: Tiempos Involucrados en las Colisiones a) ALOHA b) ALOHA Ranurado.

ALOHA Ranurado Es una mejora a ALOHA que consiste en dividir el tiempo para la emisi´on de frames en intervalos de duraci´on constante del tama˜ no de un frame. Adem´as, los nodos deben sincronizarse para saber cuando empieza cada intervalo. Esto reduce la probabilidad de colisi´on, ya que limita el efecto de colisi´on a un intervalo concreto, y no se pueden encadenar colisiones. En ALOHA ranurado, la eficiencia m´axima es de 36,8 % y se consigue con una utilizaci´on del 100 % del canal. 2.5.5.

Protocolos de Acceso M´ ultiple Con Detecci´ on de Portadora

Estos protocolos antes de transmitir observan si alguien ya est´a transmitiendo, lo que permite hacer un uso m´as eficiente del canal ya que no se interrumpe la transmisi´on que est´a en proceso. El nombre gen´erico de estos protocolos es de acceso m´ ultiple con detecci´ on de portadora o CSMA. CSMA 1-persistente El protocolo CSMA 1-persistente funciona de la siguiente forma: cuando tiene que transmitir un frame, primero escucha el canal y si est´a libre env´ıa el frame, caso contrario, espera a que se libere y en ese momento lo env´ıa. Se denomina CSMA 1-persistente porque existe la probabilidad 1, es decir, certeza de que el frame se transmitir´a cuando el canal est´e libre. En una situaci´on real con alto tr´afico es muy posible que cuando un nodo termine de transmitir existan varios esperando enviar sus datos, y con CSMA 1-persistente todas los frames ser´an emitidos a la vez y colisionar´an, pudi´endose repetir el proceso varias veces con la consiguiente degradaci´on del rendimiento. Cabe se˜ nalar que una colisi´on ocurrir´a aunque no empiecen a transmitir exactamente a la vez, basta simplemente con que dos nodos empiecen 42

a transmitir con una diferencia de tiempos menor que la distancia que los separa, ya que en tal caso ambos detectar´an el canal libre en el momento de iniciar la transmisi´on. Se deduce entonces, que en este tipo de redes el retardo de propagaci´on de la se˜ nal puede tener un efecto importante en el rendimiento. El rendimiento obtenido con este protocolo puede llegar al 55 % con un grado de ocupaci´on del 100 %. CSMA no persistente Corresponde a una modificaci´on del protocolo anterior que funciona de la siguiente manera: antes de enviar se escucha el canal, si el canal est´a libre se transmite el frame. Si est´a ocupado, en vez de quedar escuchando, se espera un tiempo aleatorio, que viene dado por un algoritmo llamado de backoff, despu´es del cual se repite el proceso. El protocolo tiene una menor eficiencia que CSMA 1-persistente para tr´aficos moderados, pues introduce una mayor latencia; sin embargo se comporta mejor en situaciones de tr´afico intenso ya que evita las colisiones producidas por las estaciones que se encuentran a la espera de que termine la transmisi´on de un frame en un momento dado. CSMA p-persistente Este protocolo utiliza intervalos de tiempo y funciona de la siguiente manera: cuando el nodo tiene algo que enviar primero escucha el canal, si est´a ocupado espera un tiempo aleatorio. Cuando el canal est´a libre se selecciona un n´ umero aleatorio con distribuci´on uniforme entre 0 y 1, si el n´ umero seleccionado es menor que p el frame es transmitido. En caso contrario, se espera el siguiente slot de tiempo para transmitir y repite el algoritmo hasta que el frame es transmitido o bien otro nodo utiliza el canal, en cuyo caso se espera un tiempo aleatorio y empieza de nuevo el proceso desde el principio. La eficiencia del protocolo es, en general, superior a la de CSMA 1-persistente y CSMA no persistente. CSMA con Detecci´ on de Colisi´ on Un problema con los protocolos anteriores es que una vez se ha empezado a transmitir un frame se sigue transmitiendo a´ un cuando se detecte una colisi´on. Como es m´as eficiente dejar de transmitir y esperar un tiempo aleatorio para volver a hacerlo, ya que el frame ser´a err´oneo de todas formas, los protocolos de acceso m´ ultiple detecci´on de portadora con detecci´on de colisiones o CSMA/CD implementan esta mejora. En una red CSMA/CD la u ´nica circunstancia en la que puede producirse una colisi´on es cuando dos hosts empiezan a transmitir a la vez, o con una diferencia de tiempo lo bastante 43

Contienda Slots de tiempo frame frame

Libre

Transmisión frame

frame

tiempo

Figura 19: Estados de una Red CSMA/CD.

peque˜ na como para que la se˜ nal de uno no haya podido llegar al otro antes de que ´este empiece a transmitir. En palabras simples, el nodo no alcanz´o a “escuchar” que otro nodo ya comenz´o la trasmisi´on, producto del retardo de propagaci´on de la se˜ nal. Suponiendo que se tienen los nodos de los extremos de la red, llamados A y B y que la se˜ nal tarda un tiempo t en propagarse de uno a otro extremo a otro, cabr´ıa pensar que si A empieza a transmitir pasado ese tiempo t puede estar seguro de que no detectar´a colisiones, ya que su se˜ nal ha llegado al otro extremo de la red. En el peor caso, B podr´ıa haber empezado a transmitir justo en el instante t-e, es decir, inmediatamente antes de que le haya llegado el frame de A, por lo que s´olo despu´es de un tiempo 2t, el nodo A puede estar seguro de no colisionar con ninguna otra estaci´on. A este per´ıodo de tiempo se le llama per´ıodo de contienda y corresponde a uno de los tres posibles estados que tiene una red CSMA/CD, los otros dos estados son los de transmisi´on y el estado libre (Figura 19). 2.5.6.

Protocolos Libre de Colisiones

El problema de las colisiones es que en la pr´actica producen una disminuci´on del rendimiento debido a que las transmisiones que se producen durante la colisi´on son in´ utiles, el problema se acrecenta al aumentar el tr´afico en la red. En cambio, los protocolos que por su funcionamiento no tienen colisiones, suelen tener una mayor eficiencia cuando la carga de la red es elevada.

1

1

Período de Reserva

Frame 0

Frame 2

Período de Transmisión

1 1 1 Período de Reserva

Frame 0

Frame 1

Período de Transmisión

Figura 20: El protocolo Bitmap.

44

Frame 2

Protocolo Bit-Map Suponiendo que la red tiene N nodos, numerados de 0 a N-1. Para empezar a funcionar, se establece una ronda exploratoria de N intervalos en la que por turno cada host, empezando por el 0, tiene la posibilidad de enviar un bit con el valor 0 ´o 1 para indicar si tiene alg´ un frame que transmitir. Pasados los N intervalos todos los hosts han manifestado su situaci´on y todos saben quien tiene datos para transmitir. Luego, ordenadamente cada host que ten´ıa datos para transmitir lo hace, una vez finalizado esto se vuelve ha establecer una nueva ronda exploratoria. Si a alg´ un host le surge la necesidad de transmitir justo despu´es de haber dejado pasar su turno, tendr´a que esperar a la siguiente vuelta (Figura 20). Considerando el rendimiento, este protocolo genera un frame adicional de N bits. Si la red no tiene tr´afico, se genera un frame bitmap que est´a continuamente dando vueltas por la red. Si la carga en la red es baja (un frame transmitido por vuelta) la eficiencia es

d , N +d

con d el

tama˜ no del frame de informaci´on transmitida y N el n´ umero de nodos. Si la red est´a saturada existir´a un frame por host que enviar y la eficiencia ser´a

d . d+1

Esto muestra que el rendimiento

de este protocolo aumenta a medida que lo hace el tr´afico en la red. Un problema con este protocolo es que la calidad de servicio que ofrece a cada nodo no es la misma. En situaciones de poco tr´afico el protocolo bitmap no da un trato equitativo, sino que favorece a los nodos con direcci´on elevada. En cambio en situaciones de saturaci´on este efecto desaparece, ya que si todos los hosts tienen frames que enviar cada uno podr´a transmitir una frame a la vez. En resumen, el protocolo bitmap es m´as eficiente y m´as homog´eneo en su comportamiento a medida que la carga de la red aumenta. Protocolo de Cuenta Regresiva Binaria El usar un bit para reservar implica una sobrecarga muy grande si en n´ umero de nodos es alto. En cambio, el protocolo de cuenta regresiva binaria usa direcciones binarias de largo fijo. El protocolo funciona de la siguiente forma: los nodos que desean transmitir env´ıan a la red el bit m´as significativo de su direcci´on, el medio de transmisi´on est´a dise˜ nado de tal forma que retransmite el OR de todos los bits transmitidos. Con este resultado, los nodos que desean transmitir y que tengan el bit menor al obtenido en el medio se retiran de la competencia. Los nodos restantes env´ıan el siguiente bit de direcci´on hasta que quede s´olo un nodo (el de mayor direcci´on) que ser´a el que transmita. El proceso se repite despu´es con los nodos que a´ un no han transmitido. La eficiencia de este protocolo supera al bitmap para tr´aficos reducidos.

45

2.5.7.

Protocolos de Contenci´ on Limitada

Los protocolos con colisiones son ideales cuando los niveles de tr´afico son bajos, ya que tienen retardos peque˜ nos y no introducen overhead. En cambio, cuando el tr´afico aumenta, es preferible perder una parte de la capacidad del canal en habilitar mecanismos que posibiliten turnos de transmisi´on, ya que de lo contrario no es posible utilizar el canal al m´aximo de sus posibilidades. Cuando la red tiene poco tr´afico, los protocolos de contenci´on limitada se comportar´an seg´ un alguno de los protocolos con colisiones ya vistos. Cuando se superan determinados niveles de utilizaci´on, el protocolo dividir´a el canal en intervalos asignando uno a cada host. En la pr´actica suelen ser unos pocos nodos los que generan la mayor parte del tr´afico, por lo que lo ideal es identificarlos y aislarlos en intervalos propios, independientes del resto de los hosts. De esta forma, esos nodos con tr´afico elevado consiguen un buen rendimiento sin perjudicar a la mayor´ıa que es la que no transmite tanto. La r´apida identificaci´on de nodos con alto tr´afico es la clave del funcionamiento de estos protocolos. Debe hacerse notar que para efectos de operaci´on, los hosts con alto tr´afico no necesariamente deben ser identificados individualmente, es suficiente detectar un grupo con tr´afico elevado y aislarlo del resto para que el protocolo funcione de buena forma. 2.5.8.

Protocolos Token Passing

Estos protocolos se pueden considerar como un conjunto de l´ıneas punto a punto simplex que interconectan nodos en un anillo, que puede ser l´ogico y/o f´ısico. Los frames se transmiten en un determinado sentido dentro del anillo y dan la vuelta completa, lo que para efectos pr´acticos implica que la red funciona como un medio broadcast. Cada estaci´on de la red puede funcionar en uno de los dos modos siguientes: Modo escucha. Cada frame que se recibe del nodo anterior se transmite al siguiente. Modo transmisi´ on. El nodo emite un frame hacia el siguiente nodo, y paralelamente, recibe y procesa los bits que le llegan del nodo anterior en el anillo. En un determinado momento, s´olo un nodo de la red puede estar en modo transmisi´on, y los dem´as deben estar a la escucha. Si no hay tr´afico en la red todos los nodos est´an escuchando. Un protocolo token passing funciona de la siguiente manera (Figura 21):

46

a)

b)

c)

d)

e)

f)

Figura 21: Operaci´on del protocolo Token Passing a) Token flota libremente b) Token es capturado y se emite frame c) Frame es copiado en destino d) y e) y f) Frame es recuperado en el origen y el Token es liberado

Cuando ning´ un host desea transmitir, todos est´an en modo escucha y se env´ıa por el anillo un frame especial denominado token. El token va pasando de un host a otro indefinidamente (Figura 21a)). Cuando alg´ un nodo desea transmitir debe esperar a que pase por ´el el token. En ese momento, se apodera de ´este, t´ıpicamente convirtiendo el token en el delimitador de inicio del frame. A partir de ese momento, el nodo pasa a modo transmisi´on y env´ıa el frame al siguiente nodo(Figura 21b)). Todos los dem´as hosts del anillo, incluido el destino, siguen en modo escucha, retransmitiendo el frame recibido hacia el siguiente nodo. El host destino, adem´as de retransmitirlo, retiene una copia del frame que pasar´a al nivel de red para su proceso (Figura 21c)). ´ Al finalizar la vuelta, el emisor empieza a recibir su propio frame. Este puede optar por descartarlo o compararlo con el frame enviado para verificar si la transmisi´on ha sido correcta Figura 21e)). Cuando el nodo ha terminado de transmitir el u ´ltimo bit del frame pueden ocurrir dos 47

cosas: que restaure el token en el anillo inmediatamente, o que espere hasta recibir, de la estaci´on anterior, su frame, y s´olo entonces restaure el token Figura 21f)). El primer modo de funcionamiento recibe un nombre especial, y se le conoce como Early Token Release. Si el emisor tiene varios frames listos para emitir puede enviarlos sin liberar el token, hasta consumir el tiempo m´aximo permitido, denominado token-holding time. Una vez agotados los frames que hubiera en el buffer, o el tiempo permitido el nodo restaura el token en el anillo. Bajo ninguna circunstancia un host debe estar en modo transmisi´on durante un tiempo superior al token-holding time. Este protocolo genera problemas nuevos: ¿qu´e pasa si se pierde un frame? ¿ qu´e pasa si el nodo encargado de regenerar el token falla?. En toda red token passing existe una estaci´on monitora que se ocupa de resolver estas situaciones y garantizar el normal funcionamiento del protocolo. En caso de problemas restaurar´a un token en el anillo para que el tr´afico pueda seguir circulando normalmente. Cualquier estaci´on de una red token passing est´a capacitada para actuar como monitor en caso necesario. Cuando un nodo se a˜ nade a la red queda a la escucha en busca de tokens o datos. Si no detecta actividad, emite un frame de control especial denominado claim token. Si existe ya un monitor ´este responder´a con un token a la petici´on. Si no, el reci´en incorporado recibir´a su propio claim token, momento en el cual pasar´a a constituirse en monitor. Existe tambi´en un mecanismo de prioridades, el que funciona de la siguiente manera: existen bits en el frame que permiten establecer la prioridad de un nodo, por lo que nodos de mayor prioridad podr´an tomar el control del token aunque alg´ un host, pero de menor prioridad, est´e transmitiendo. Una vez finalizada la transferencia, se debe devolver la prioridad que ten´ıa al token. 2.5.9.

Protocolos de Redes Inal´ ambricas

La transmisi´ on inal´ ambrica Actualmente han aparecido redes locales basadas en ondas de radio e infrarrojos. T´ıpicamente una LAN inal´ambrica est´a formada por un conjunto de estaciones base, unidas entre s´ı por alg´ un tipo de cable, y una serie de estaciones m´oviles que comunican con la estaci´on base m´as pr´oxima. El conjunto de estaciones base forma en realidad un sistema celular en miniatura. Una red de este tipo presenta nuevos problemas al control de acceso al medio, entre estos 48

10 m.

10 m. B

A

a)

Colisión Tx A-B

C

Tx C-B

Tx A-B A

10 m.

B

b)

D Tx C-B

C

D

No puede Tx Tx B-A A

Tx B-A B

Tx C-D C

D

c)

Figura 22: Red LAN Inal´ambrica.

cabe destacar que no puede darse por sentado que todos los nodos tienen acceso a escuchar si cualquiera de los posibles emisores est´a utilizando el canal (recordar que el alcance es limitado), por lo tanto, el sensar el canal puede no llegar a u ´til. Adem´as de esto, es necesario considerar que no resulta pr´actico tener un canal (frecuencia) para transmitir y otro distinto para recibir. Por otra parte, deben considerarse aspectos provenientes de la naturaleza de la situaci´on: en primer lugar, las transmisiones son omnidireccionales y, en segundo lugar, las colisiones ocurren en el radio del receptor, pues no son “importantes” para el emisor como es en el caso de CSMA/CD. Finalmente, un elemento no menor a considerar tiene que ver con la potencia consumida por un elemento que continuamente est´e sensando el canal para transmitir. Esto, en el caso de usuario m´oviles implicar´ıa un excesivo consumo de bater´ıas, situaci´on que no es deseada. Las consideraciones anteriores llevan a la generaci´on de dos nuevos problemas a resolver en las comunicaciones inal´ambricas. Si se supone lo siguiente: existen cuatro nodos A, B, C y D situados en l´ınea y separados, por ejemplo, 10 metros (Figura 22a)), el alcance m´aximo de cada uno de ellos es un poco mayor que la distancia que los separa, por ejemplo, 12 metros; y el protocolo de transmisi´on a utilizar ser´a CSMA (notar que esto expresamente lleva a sensar el canal antes de transmitir). La secuencia de sucesos para transmitir un frame podr´ıan ser la siguiente: A desea transmitir datos a B, al detectar el medio lo encuentra libre y comienza la transmisi´on. A est´a transmitiendo a B y C tambi´en desea transmitir datos hacia B, detecta el medio y lo encuentra libre (C no escucha a A pues esta a 20 m de distancia), por lo tanto, C empieza a transmitir.

49

El resultado es una colisi´on en el receptor B que no es detectada ni por A ni por C. Esto se conoce como el problema de la estaci´on oculta (Figura 22b)). Si ahora, con la misma distribuci´on de nodos, ocurre lo siguiente: B desea transmitir datos hacia A, detecta el medio libre e inicia la transmisi´on. A continuaci´on, C desea transmitir datos hacia D, y como detecta que B est´a transmitiendo espera a que termine para evitar una colisi´on. El resultado es que una transmisi´on que en principio podr´ıa haberse hecho sin interferencias (ya que A no puede escuchar a C y D no puede escuchar a B) no se lleva a cabo, reduciendo as´ı la eficiencia del sistema. Esto se conoce como el problema de la estaci´on expuesta (Figura 22c)). Notar que la trasmisi´on puede llevarse a cabo si no se sensa el canal, y no existir´an problemas de colisiones, debido a que est´as tienen efecto s´olo en el receptor, el cual es inalcanzable en este caso. CSMA/CA Carrier Sense Multiple Access with Collision Avoidance o CSMA/CA es un protocolo que sensa el canal antes de producir una transmisi´on, y si ´este est´a ocupado utiliza un algoritmo de backoff para volver a sensar el canal hasta encontrarlo libre. Una vez que el canal est´a libre, resuelve los problemas mencionados haciendo handshaking de se˜ nales RTS (Request To Send) CTS (Clear To Send) DATA (Datos). RTS y CTS son frames peque˜ nos que tienen informaci´on de quienes son las estaciones transmisoras, receptoras y cuanto tiempo durar´a la transmisi´on. En el caso de la estaci´on oculta, A sensa el canal, si lo encuentra libre transmite un RTS a B indicando la longitud del frame que desea enviar. B responde con un CTS que tambi´en especifica la longitud del frame a recibir. En este momento C capta la respuesta de B, por lo que se percata de que va a tener lugar una transmisi´on en la que B actuar´a de receptor y sabe que deber´a permanecer en silencio durante el tiempo que dure la transmisi´on (C sabe lo que durar´a pues conoce la longitud del frame y la velocidad de la red). Con esto, A env´ıa los datos a B, y C puede transmitir a B una vez pasado el tiempo que ´el sabe debe esperar para poder comunicarse. En el caso de la estaci´on expuesta B transmite a A un RTS indicando que quiere enviarle datos. En ese momento C se entera de las intenciones de B. A devuelve a B un CTS. Mientras tanto, C, ha captado el RTS pero no puede comunicarse con D, o al menos trasferir los datos pues debe enviar primero un RTS, pero el canal estar´a ocupado pues debe esperar a que B termine. Si bien se soluciona correctamente el problema de la estaci´on oculta, el sensar el medio hace que el problema no se resuelva (eficientemente al menos).

50

MACA Multiple Access with Collision Avoidance o MACA es un protocolo MAC resuelve los problemas antes mencionados haciendo handshaking de se˜ nales RTS-CTS-DATA sin sensar el canal, de ah´ı que el nombre sea MACA y que en ninguna parte de ´el lleve la parte CS. Cuando una estaci´on tiene un frame que transmitir, antes de enviarlo, y sin sensar el canal, env´ıa un frame RTS, el nodo destino, al recibir el RTS, y si est´a en condiciones de recibir la transmisi´on, responde con un CTS. En el caso de la estaci´on oculta ocurre lo siguiente: sin sensar el canal, A transmite un RTS a B, y B responde con un CTS. C capta la respuesta de B, conociendo entonces que habr´a una transmisi´on en la que B actuar´a de receptor, por lo que deber´a permanecer en silencio durante el tiempo que dure la transmisi´on. A env´ıa a B los datos correspondientes y una vez finalizado esto (pasado el tiempo) C puede transmitir a B. En el caso de la estaci´on expuesta ocurre lo siguiente: B transmite a A un RTS indicando que quiere enviarle datos. En ese momento C se entera de las intenciones de B. A devuelve a B un CTS. Mientras tanto, C, que ha captado el RTS pero no el correspondiente CTS, comprende que aunque detecta que B est´a transmitiendo el destinatario est´a fuera de su alcance, por lo que puede comunicar con D cuando quiera, sin esperar a que B termine. En este algoritmo tambi´en pueden ocurrir colisiones, como por ejemplo que choquen dos RTS vecinos. La soluci´on se encuentra en que el o los nodos destinos no devolver´an un CTS, por lo que pasado un cierto timeout, se implementar´a un algoritmo de retransmisi´on que permitir´a a los emisores generar un nuevo RTS. MACAW MACA Wireless es una versi´on mejorada del protocolo anterior que funciona de manera similar, pero ahora utiliza un intercambio de mensajes RTS-CTS-DS(Data Send)-DATAACK(Acknowledge), adem´as de implementar modificaciones al algoritmo de retransmisi´on o de backoff. La utilizaci´on de un frame de ACK en este nivel mejora los tiempos de respuesta, compar´andolos con los que se obtendr´ıa si se dejara manejar la situaci´on por el protocolo de nivel de transporte. El nuevo frame CS permite distribuir la informaci´on de sincronizaci´on sobre los per´ıodos de contienda, de forma que los nodos puedan “pelear” de igual forma por un slot de tiempo para solicitar la transmisi´on. La trasmisi´on se lleva a cabo de la siguiente manera, el emisor env´ıa (sin sensar el canal) un RTS al receptor, quien responder´a con un CTS, una vez recibido ´este, el emisor env´ıa un DS seguido de los datos a transmitir. En caso de recibirse correctamente los datos el receptor 51

devuelve un ACK, caso contrario no lo hace y se retransmite la informaci´on siguiendo el mismo esquema partiendo con el RTS. En el caso de que el ACK se pierda, se enviar´a un nuevo RTS al cual se le responder´a nuevamente con el mismo ACK.

2.6.

Estandarizaci´ on de Redes LAN

La mayor´ıa de las LANs han sido estandarizadas por el IEEE, en el comit´e denominado 802. Los est´andares desarrollados por este comit´e est´an enfocados a las capas 1 y 2 del modelo OSI. Este comit´e se divide en subcomit´es, cuyo nombre oficial es Grupos de Trabajo, que se identifican por un n´ umero decimal (ver tabla 1). Los grupos de trabajo 802 continuamente est´an planteando nuevas t´ecnicas y protocolos para su estandarizaci´on, nuevos medios f´ısicos, etc. Al surgir una propuesta, el grupo correspondiente nombra un grupo de estudio que la analiza, y si el informe es favorable se crea un subgrupo que eventualmente propone un adendum al est´andar para su aprobaci´on. Los proyectos se identifican por letras a˜ nadidas al grupo de trabajo del que provienen. Por ejemplo: 802.1d: puentes transparentes 802.1g: puentes remotos 802.1p: Filtrado por clase de tr´afico (Calidad de Servicio) 802.1q: Redes locales virtuales (VLANs) 802.3u: Fast Ethernet 802.3x. Ethernet Full d´ uplex y control de flujo 802.3z: Gigabit Ethernet 802.3ab: Gigabit Ethernet en cable UTP-5 802.3ae: 10 Gigabit Ethernet

52

802.1

Tabla 1: Grupos de Trabajo del Comit´e 802 de IEEE. Aspectos comunes: puentes, gesti´on, redes locales virtuales, etc.

802.2

Logical Link Control (LLC). En hibernaci´on e inactivo

802.3

Redes CSMA/CD (Ethernet)

802.4

Redes Token-Passing Bus. En hibernaci´on e inactivo

802.5

Redes Token Ring

802.6

Redes MAN DQDB (Distributed Queue Dual Bus). En hibernaci´on e inactivo

802.7

Grupo asesor en redes de banda ancha. En hibernaci´on e inactivo.

802.8

Grupo asesor en tecnolog´ıas de fibra ´optica

802.9

Redes de servicios Integrados (Iso-Ethernet). En hibernaci´on e inactivo

802.10

Seguridad en est´andares IEEE 802. En hibernaci´on e inactivo.

802.11

WLAN (Wireless LANs)

802.12

Redes Demand Priority (100VG-AnyLAN). En hibernaci´on e inactivo

802.14

Redes de TV por cable, pendiente de ratificaci´on. Disuelto.

802.15

WPAN (Wireless Personal Area Network)

802.16

BWA (Broadband Wireless Access)

2.7.

Tecnolog´ıas Ethernet

Ethernet se refiere a la familia de implementaciones LAN que usan CSMA/CD como protocolo MAC, y se incluyen tres categor´ıas principales: Ethernet Original. Es el sistema m´as utilizado actualmente, transmite frames a 10 Mbps y est´a especificado por los est´andares IEEE 802.3 y Ethernet. FastEthernet. Es un sistema con un ancho de banda de 100 Mbps. Uno de los aspectos importantes de Fast Ethernet, es que conserva el formato del frame Ethernet y la cantidad de datos que pueden ser transmitidos en ´el, lo que lo hace ser compatible con la versi´on anterior. GigabitEthernet. Corresponde a una extensi´on m´as del est´andar de Ethernet. Este sistema ofrece un ancho de banda de 1000 Mbps, manteniendo absoluta compatibilidad con los nodos Ethernet ya existentes.

53

2.7.1.

Especificaci´ on IEEE 802.3 y Ethernet

Medio F´ısico La tabla 2 muestra los tipos de medios f´ısicos posibles de utilizar en la especificaci´on. Actualmente casi todo el cable de cobre utilizado en redes Ethernet es el de UTP categor´ıas 3 y 5 preferentemente. Rara vez se emplea STP o cable coaxial. Tabla 2: Medios F´ısicos m´as Utilizados Especificados en IEEE 802.3. 10Base5

10Base2

10Base-T

10Base-FL

Cable

Coaxial grueso

Coaxial delgado

UTP Cat 3/5

Fibra 62,5/125 micras

Pares

1

1

2/2

2

Full d´ uplex

No

No

S´ı/S´ı

S´ı

Tipo Conector

N

BNC

RJ-45/RJ-45

ST

Topolog´ıa

Bus

Bus

Estrella/Estrella

Estrella

Dist. Seg.

500, m´ax 2500 m

185, m´ax 925 m

100, m´ax 500 m

2 km

100, m´ax 500 m o

N Nodos/seg.

100

30

1024/1024

1024

En Ethernet, como en todas las redes locales, la transmisi´on es realizada de manera asincr´onica. Por esto, se utiliza un sincronismo impl´ıcito en los datos mediante el uso de c´odigos que incorporan cierto nivel de redundancia. Ethernet usa el c´odigo Manchester, que utiliza dos voltajes e identifica el bit 0 como una transici´on alto-bajo y el 1 como una transici´on bajoalto. El c´odigo Manchester es poco eficiente, pero resulta sencillo y barato de implementar. Su mayor inconveniente resulta ser la elevada frecuencia de la se˜ nal, lo que complic´o bastante las cosas cuando se adapt´o Ethernet para UTP. Como medida de confiabilidad del medio f´ısico, el est´andar 802.3 establec´ıa inicialmente una BER m´axima de 10−8 , pero las nuevas especificaciones de medios f´ısicos han ido fijado requerimientos superiores. Una buena instalaci´on Ethernet actual en un entorno de oficina puede dar sin problemas una BER inferior a 10−12 . Transmitiendo a 10 Mbps ininterrumpidamente esto representa menos de un error por d´ıa, lo que implica que los errores de CRC en una red Ethernet funcionando correctamente deber´ıan ser casi nulos, salvo los originados por la conexi´on y desconexi´on de equipos. Debido a la elevada confiabilidad del medio f´ısico, el protocolo MAC de Ethernet no realiza ning´ un tipo de verificaci´on, ya que la probabilidad de 54

que un frame no llegue a su destino es tan baja que esto ser´ıa perjudicial para el rendimiento de la red.

1B 6B S Dir. Preámbulo O Destino F

6B

2B

0-1500 B

0-46 B

4B

Dir. Fuente

Tipo

Datos

Relleno

CRC

7B

a) 8B

6B

6B

2B

0-1500 B

0-46 B

4B

Preámbulo

Dir. Destino

Dir. Fuente

Largo

Datos

Relleno

CRC

b)

Figura 23: Formato de un frame a) Ethernet b) IEEE 802.3.

Subcapa MAC Ethernet e IEEE 802.3 utilizan el protocolo CSMA/CD, y el formato de un frame de datos es el mostrado en la Figura 23. El detalle de los campos es el siguiente: Pre´ ambulo. 1 Byte, es un delimitador consistente en la secuencia 10101010 repetida 7 veces. En el caso de un frame Ethernet el campo SOF indica que se procede a comenzar a recibir un frame. En el caso del frame IEEE 802.3 el campo Pre´ambulo tiene un byte m´as, que toma el valor 10101011 si se proceder´a a recibir un frame. SOF. (s´olo en IEEE) 1 Byte delimitador del frame Ethernet terminado con dos bits en 1 consecutivos (10101011), que sirven para sincronizar las porciones de recepci´on de frames de los nodos. Direcciones destino y origen. 6 Bytes para cada direcci´o, que corresponden a los identificadores de los nodos de una LAN. Los primeros 3 bytes de las direcciones son asignados por el IEEE a cada fabricante, y los tres u ´ltimos son especificados por el fabricante. La direcci´on de origen siempre es unicast, la destino puede ser uni, multi o broadcast. Estas son las llamadas direcciones MAC. Tipo. (s´olo en Ethernet) 2 Bytes que identifican el protocolo de la capa superior que recibir´a los datos una vez recibido el frame.

55

Largo. (s´olo en IEEE) 2 Bytes que especifican el n´ umero de bytes de datos que contiene el campo Datos que siguen a continuaci´on en el frame. Datos. corresponde a los datos provenientes de las capas superiores. Un frame debe tener un tama˜ no m´ınimo de 64 bytes (a partir del campo direcci´on destino), por lo tanto, se utiliza un relleno si es que la situaci´on lo requiere. CRC. 4 Bytes, es una suma de verificaci´on para asegurar que el frame lleg´o en buen estado. La Figura 24 muestra un frame Ethernet real, de tama˜ no 67 bytes (sin contar CRC, pre´ambulo ni SOF), capturado usando un sniffer. Este frame corresponde a una parte de una sesi´on de lectura de correo electr´onico, entre m´aquinas de distintas subredes l´ogicas. En este caso, los ´ovalos muestran las direcciones MAC destino (08:00:20:73:44:51) y fuente (00:80:AD:C8:4E:6F) adem´as del campo tipo en este caso 2048 (0x0800). Los 53 bytes restantes corresponden a los datos que transporta este nivel, que corresponden a los datos de aplicaci´on (en este caso, enviar el nombre de usuario, situaci´on marcada con cuadrados) m´as el overhead producto de las sucesivas encapsulaciones.

Figura 24: Frame Ethernet Real.

56

Direcciones MAC. Ethernet asigna direcciones globalmente u ´nicas a cada dispositivo o interfaz de red. Para ello utiliza una direcci´on de seis bytes, de los cuales los tres primeros corresponden a una identificaci´on del fabricante y los tres u ´ltimos al dispositivo. El est´andar permite direcciones de 2 ´o 6 bytes, aunque en la pr´actica s´olo se utilizan las de 6 bytes. Adem´as de utilizarse en otras redes 802 las direcciones MAC IEEE se emplean en redes locales no IEEE, como FDDI y Fibre Channel. Los dos primeros bits de los 48 que componen una direcci´on MAC IEEE tienen un significado especial: El primer bit indica el ´ambito del env´ıo. Se contemplan tres posibilidades: env´ıo unicast, multicast o broadcast. Si el primer bit est´a a 0 se trata de un env´ıo unicast, si est´a en 1 es un env´ıo multicast o broadcast. En caso de que toda la direcci´on est´e con sus bits en 1 ser´a un env´ıo broadcast (direcci´on FF:FF:FF:FF:FF:FF), que deber´a ser atendido por todos los nodos. Si es un frame multicast, tendr´a en 1 el primer bit, viniendo especificado por el resto de la direcci´on el grupo multicast al que va dirigido. En un frame unicast el primer bit ser´a 0, en cuyo caso el frame s´olo deber´a ser interpretado por el nodo al que va dirigido. El segundo bit se utiliza para indicar si se trata de una direcci´on global (grabada por el fabricante en el hardware de la tarjeta) o si se trata de una direcci´on local, asignada por software a ese equipo. Las direcciones locales s´olo pueden ser utilizadas dentro de la red, ya que en otras redes podr´ıan estar duplicadas. En cambio las globales, dado que son u ´nicas en todo el mundo, podr´ıan utilizarse para enviar frames a cualquier nodo existente. Colisiones. Para que CSMA/CD funcione bien, es decir, detecte las colisiones, se requiere que el tiempo de ida y vuelta entre dos estaciones cualquiera no supere el tiempo de transmisi´on m´ınimo, que corresponde al tiempo que tarda en emitirse el frame de tama˜ no m´ınimo permitido. El tiempo de transmisi´on m´ınimo depende exclusivamente de la velocidad de operaci´on de la red, y el tiempo m´aximo de ida y vuelta o round trip time fija las distancias m´aximas entre los nodos. Estos cuatro par´ametros: velocidad de la red, tama˜ no de frame m´ınimo, round trip time y distancia m´axima est´an relacionados entre s´ı. Se producir´a una colisi´on cuando dos o m´as nodos empiecen a transmitir simult´aneamente, 57

o con una separaci´on de tiempo menor que el tiempo de propagaci´on que las separa. En Ethernet se producir´a una colisi´on siempre que dos nodos transmitan con una separaci´on en el tiempo menor de 25.6 µseg., que corresponde a la mitad del tiempo de transmisi´on del frame m´ınimo permitido. Si la separaci´on es mayor que 25.6 µseg. no se producir´a colisi´on ya que el segundo nodo detectar´a el medio ocupado cuando vaya a transmitir. En ese caso, esperar´a a que el primero termine y transmitir´a a continuaci´on, respetando el tiempo entre frames que debe existir, y que para Ethernet es de 9.6 µseg. A pesar de que transcurridos los 25.6 µseg. ya no puede ocurrir colisi´on, para el emisor no existe garant´ıa de no colisi´on sino s´olo hasta pasados 2*25.6=51.2 µseg., ya que si otra estaci´on empieza a transmitir justo antes de que el frame alcance el otro extremo de la red se producir´a una colisi´on en el lugar m´as distante, de la que el emisor se informar´a s´olo cuando vuelva el frame, tendr´an que haber transcurrido en total los 51.2 µseg. En caso de producirse una colisi´on, los nodos Ethernet utilizan el algoritmo de backoff o retroceso exponencial binario para iniciar la retransmisi´on. Al detectar la colisi´on, los involucrados dejan de transmitir y a partir de ese momento dividen el tiempo en intervalos de 51.2 µseg. y esperan 0 ´o 1 intervalos para reintentar. La elecci´on entre 0 y 1 la hace cada uno independientemente de forma aleatoria, por lo que la probabilidad de colisi´on es de 0.5. Si se produce una segunda colisi´on, cada nodo espera aleatoriamente 0, 1, 2 ´o 3 intervalos para reintentar, bajando la probabilidad de colisi´on a 0.25. Si siguen colisionando el n´ umero de intervalos se duplica en cada intento sucesivo, con lo que la probabilidad de colisi´on decrece exponencialmente, hasta que los nodos eligen intervalos distintos. As´ı, quien eligi´o el intervalo m´as bajo transmite primero y as´ı sucesivamente. El algoritmo tiene un tope m´aximo de intentos, al final del cual produce un error de transmisi´on. El Rendimiento de Ethernet Probablemente el factor que m´as influye en el rendimiento de Ethernet es el tama˜ no del frame utilizado. Debido a que una colisi´on s´olo puede suceder durante los primeros 512 bits del frame, se puede decir que cuando ´esta tiene 512 bits de longitud el riesgo de colisi´on es permanente, mientras que si tiene el m´aximo, es decir, 1518 bytes la colisi´on s´olo puede producirse durante los primeros 512 bits, es decir el 4.2 % del tiempo. Por lo tanto, dado un nivel de ocupaci´on constante, el n´ umero de colisiones se reduce, y el rendimiento aumenta, si aumenta el tama˜ no de los frames. Otro factor que influye en la eficiencia, es el n´ umero de estaciones emisoras. Esto se puede comprender f´acilmente d´andose cuenta de que la probabilidad de generar colisiones 58

aumenta en la medida que aumenta el n´ umero de posibles transmisores en la red, debido a la competencia por el medio f´ısico. Un tercer par´ametro que influye en el rendimiento es el round trip time. Como es sabido, las colisiones siempre ocurren dentro de los primeros 512 bits del frame, es m´as, ocurrir´an s´olo en el bit 512 cuando se est´e transmitiendo a la distancia m´axima de la red. Por otro lado, si la separaci´on entre nodos es menor, entonces se reduce el round trip time entre ellos, con lo que se reduce el tiempo de colisi´on entre ellas, lo que implica una menor probabilidad de colisi´on. A la inversa, dada una misma topolog´ıa de red, tama˜ no de frame, n´ umero de estaciones y nivel de ocupaci´on relativa, la probabilidad de colisi´on disminuye a medida que aumenta la velocidad de operaci´on de la red, ya que el valor de round trip time disminuye. 2.7.2.

Especificaci´ on IEEE 802.3u Fast Ethernet

A causa de la importancia que han cobrado las redes, f´acilmente caen en congesti´on debido a su propio crecimiento. Esto, unido al crecimiento en el n´ umero de aplicaciones hace cada vez mayor la necesidad de velocidad. En respuesta a ello, han surgido tecnolog´ıas de redes de amplio ancho de banda entre las que se incluyen ATM, FDDI, 100VG-AnyLAN y Fast Ethernet. Fast Ethernet provee muchas ventajas, entre las que se cuentan: estar basado en el est´andar IEEE 802.3, una velocidad de 100 Mbps y la maximizaci´on del uso de administraci´on, equipo y cableado existente, manteniendo la esencia de Ethernet y encarg´andose s´olo de hacerla m´as r´apida bajo la misma estructura. Esto permite la f´acil migraci´on de Ethernet a Fast Ethernet. Por otro lado, como ambas emplean CSMA/CD, los datos pueden pasar de una a otra sin necesitar ning´ un tipo de protocolo de traducci´on. Esta capacidad permite instalar una red por fases, ya que se puede integrar una 100Base-T a una 10Base-T con s´olo usar un puente 10/100. Medio F´ısico Fast Ethernet puede correr a trav´es de la misma variedad de medios que 10BaseT: UTP, STP y fibra, pero no soporta cable coaxial. La especificaci´on define tres tipos de medios con una subcapa f´ısica separada para cada tipo de medio: 100Base-TX, 100Base-T4, 100Base-FX. Ver tabla 3. 100Base-TX define la especificaci´on a trav´es de dos pares de categor´ıa 5 de cable UTP o dos pares de tipo 1 de cable STP. 100Base-TX adopta el mecanismo de se˜ nalizaci´on fullduplex de FDDI (ANSI X3T9.5) para trabajar con la Ethernet MAC. Un par de cables es 59

Tabla 3: Medios F´ısicos Especificados en IEEE 802.3u. 100Base-TX 100Base-T4 100Base-FX Cable

UTP Cat 5

UTP Cat 3/5

Fibra 62,5/125 micras

Pares

2

4

2

Full d´ up

S´ı

No

S´ı

RJ-45

RJ-45

SC

Topolog´ıa

Estrella

Estrella

Estrella

Dist. Seg.

100, m´ax 200 m

100, m´ax 200 m

400 m

Tipo Conector

utilizado para transmitir, con codificaci´on 4B/5B, y el otro par es utilizado para detectar colisiones y recibir datos. La especificaci´on 100Base-T4 utiliza pares de categoria 3, 4 o 5 UTP. 100Base-T4 es halfduplex y usa tres pares para transmisi´on 100 Mbps y el cuarto par para detecci´on de colisiones. A diferencia del anterior, utiliza el c´odigo ternario 8B6T. La capa f´ısica 100Base-FX define la especificaci´on a trav´es de dos hilos de fibra de 62.5/125 micras. Utiliza una fibra para la transmisi´on y la otra fibra para detecci´on de colisiones y recepci´on.

Subcapa LLC

Capa Enlace

Subcapa MAC Subcapa MII

Capa Física 100Base-TX

100Base-T4

100Base-FX

Modelo OSI

Figura 25: Ubicaci´on de la Subcapa MII en el Modelo OSI.

Media Independent Interface El MII es una especificaci´on nueva que define una interface est´andar entre la subcapa MAC y cualquiera de las tres capas f´ısicas: 100Base-TX, 100Base-T4, y 100Base-FX (Figura 25). Su funci´on principal es ayudar a la subcapa de convergencia a hacer uso del rango de bits 60

m´as alto y diferentes tipos de medio transparente a la subcapa MAC. Es capaz de soportar 10 Mbps y 100 Mbps. Puede ser implementada en un dispositivo de red tanto interna como externamente. Internamente conecta la subcapa MAC directamente a la capa f´ısica. MII tambi´en define un conector de 40 pines que puede soportar transceivers externos. Un uso del transceiver adecuado puede conectar estaciones de trabajo a cualquier tipo de cables instalados, muy parecido a un conector AUI para 10 Mbps Ethernet. Subcapa MAC La subcapa MAC est´a basada en el protocolo CSMA/CD al igual que Ethernet. CSMA/CD tiene un round trip time m´aximo de 51.2 µseg. y un tama˜ no m´ınimo de frame de 512 bits y para Fast Ethernet la velocidad de operaci´on de la red es de 100 Mbps. Con esto, Fast Ethernet reduce el tiempo de duraci´on de cada bit que es transmitido en un factor de 10, permitiendo que la velocidad del frame se incremente. El formato y longitud del frame se mantuvieron, por lo que el round trip time y intervalo entre frames se reducen tambi´en en un factor de 10. Todo esto hace que no se requiera traducci´on de protocolo para moverse entre Ethernet y Fast Ethernet. Auto-Negociaci´ on La especificaci´on IEEE 802.3u describe un proceso de negociaci´on que permite a los dispositivos de red intercambiar informaci´on autom´aticamente sobre sus capacidades y desarrollar la configuraci´on necesaria para operar juntos en su nivel com´ un m´aximo. La auto-negociaci´on es desarrollada utilizando Fast Link Pulse (FLP) Burst para identificar la tecnolog´ıa m´as avanzada de capa f´ısica que puede ser utilizada por ambos dispositivos, como 10Base-T, 100Base-TX o 100Base-T4. Provee tambi´en una funci´on de detecci´on paralela que permite reconocer capas f´ısicas half y full-duplex 10Base-T, half y full-duplex 100Base-TX, y 100Base-T4, a´ un si uno de los dispositivos conectados no ofrece capacidades de auto-negociaci´on. El control de flujo puede ser implementado en base a enlaces o punto a punto y permite a todos los dispositivos presentes en el camino reducir la cantidad de datos que reciben. 2.7.3.

Gigabit Ethernet

Las redes Fast Ethernet se extendieron con una rapidez mayor que las expectativas m´as optimistas. Como consecuencia de esto los precios bajaron y su uso se populariz´o hasta el punto de que se utiliza Fast Ethernet incluso en la conexi´on del usuario final. Para mantener un 61

dise˜ no coherente y equilibrado de una red se requieren velocidades superiores en el backbone. Este hecho, junto con la experiencia positiva de Fast Ethernet, anim´o al subcomit´e 802.3 a iniciar en 1995 otro grupo de trabajo que estudiara el aumento de velocidad de nuevo en un factor diez, creando Gigabit Ethernet, que el 29 de junio de 1998 produjo la aprobaci´on del suplemento 802.3z. De forma an´aloga a lo hecho con Fast Ethernet, se pretend´ıa poder utilizar los mismos medios f´ısicos que en Fibre Channel: emisores l´aser con fibra ´optica multimodo y monomodo, cable de pares trenzados apantallado y adem´as cable UTP categor´ıa 5. Se puede comentar tambi´en, que siguiendo con la tradici´on ya establecida de aumentar cada vez la velocidad en un factor diez, el IEEE aprob´o en enero del 2000 la creaci´on de un grupo de estudio (IEEE 802.3ae) de alta velocidad para la estandarizaci´on de Ethernet a 10 Gigabits.

Tabla 4: Medios F´ısicos Especificados en IEEE 802.3z. 1000Base-T 1000Base-CX 1000Base-SX 1000Base-LX Cable

UTP Cat 5

STP

Fibra ´optica

Fibra ´optica

Pares

4

2

2

2

Full d´ up

S´ı

S´ı

S´ı

S´ı

RJ-45

9 pin D sub

SC

SC

Topolog´ıa

Estrella

Estrella

Estrella

Estrella

Dist. Seg.

100 m

25 m

275, m´ax 500 m

550, m´ax 5000 m

Tipo Conector

Medio F´ısico En Gigabit Ethernet existen cuatro especificaciones de medios f´ısicos: 1000BASE-T (IEEE 802.3ae), 1000BASE-SX, 1000BASE-LX y 1000BASE-CX (las tres son IEEE 802.3z). Estos emplean c´odigo 8B/10B que ya se utilizaba en Fibre Channel, de donde deriva toda la capa f´ısica de 1000BASE-X. La transmisi´on de Gigabit Ethernet por cable UTP categor´ıa 5 1000BASE-T se realiza de forma muy similar a 100BASE-T2, se utilizan 4 canales de 250 Mbps y se env´ıan los datos en paralelo por los cuatro pares. En las anteriores especificaciones, el alcance de la fibra ´optica viene limitado por la atenuaci´on de la se˜ nal, pero en Gigabit Ethernet el alcance est´a limitado fundamentalmente por el efecto del retardo en modo diferencial. Este fen´omeno consiste en que cuando el haz l´aser llega a la fibra, al ser ´esta apreciablemente m´as ancha que el haz, ´este genera haces de luz secundarios que van rebotando por las paredes al avanzar por la fibra. Este rebote no ocurre 62

exactamente igual para todos los rayos, por lo que unos realizan un trayecto un poco m´as largo que otros, con lo que el pulso de luz se ensancha ligeramente. El ensanchamiento es mayor cuanto mayor es la distancia recorrida.

Subcapa LLC

Capa Enlace

Subcapa MAC GMII (opcional)

1000BASE-X PHY Capa Física

(8B/10B Autonegociación) 1000Base-LX

1000Base-SX

1000Base-CX

1000Base-T PCS 1000Base-T

Modelo OSI

Figura 26: Arquitectura Gigabit Ethernet.

Subcapa MAC La longitud m´ınima de un frame Ethernet fija el di´ametro de la red, debido al funcionamiento de CSMA/CD. De haber mantenido el frame m´ınimo de 64 bytes en Gigabit Ethernet el di´ametro m´aximo habr´ıa sido de unos 45 m, inaceptable en la mayor´ıa de situaciones. Para evitar esto, el frame Gigabit Ethernet incorpora un segundo relleno denominado extensi´ on de portadora que se a˜ nade al final del frame para garantizar que la longitud m´ınima nunca sea inferior a 512 bytes. De esta forma, el round trip time m´aximo es de 4.096 ms y el di´ametro puede ser de unos 330 m. Este segundo relleno no es formalmente parte del frame Ethernet, por lo que solo existir´a mientras viaje por Gigabit Ethernet. De esta forma, se respetar´a la compatibilidad con los tipos anteriores de Ethernet. En el caso de que un frame con extensi´on de portadora sea transmitida a una red de 100 o 10 Mbps, ´esta se eliminar´a. Inversamente, si un frame menor de 512 bytes llega a una red Gigabit Ethernet desde otra, el switch correspondiente a˜ nadir´a la extensi´on de portadora necesaria para que la longitud sea de 512 bytes.

2.8.

Token Bus/IEEE 802.4

El problema principal que las empresas interesadas en automatizaci´on vieron con Ethernet era que ten´ıan serias dudas sobre su aplicaci´on a sistemas en tiempo real. Las razones principales eran, por un lado, el comportamiento no determinista de Ethernet, donde cab´ıa 63

la probabilidad de que dos nodos no pudieran comunicarse debido al exceso de tr´afico y, por otro, que no era posible reservar capacidad o establecer prioridades. Token Ring resolv´ıa muchos de estos problemas, pero segu´ıa presentando dos serios problemas: el papel de la estaci´on monitor resultaba demasiado importante y una topolog´ıa f´ısica bus era m´as adecuada que un anillo para una l´ınea de producci´on de una f´abrica. General Motors promovi´o entonces el desarrollo del est´andar 802.4 o Token Bus, que es una red que se utiliza en algunas f´abricas para el control de la maquinas. Cabe se˜ nalar que su uso es mucho m´as restringido que Ethernet o Token Ring, y en palabras simples, y sin cometer grandes errores, se puede decir que Token Bus es una mezcla entre Ethernet y Token Ring. Medio F´ısico Token Bus utiliza cable coaxial de 75 Ω id´entico al utilizado en TV. Se permite un bus single o doble con o sin terminadores. Se definen adem´as tres esquemas distintos de modulaci´on an´aloga: dos son tipo FSK y la restante es PSK. Las velocidades de transmisi´on son de 1, 5 o 10 Mbps. Dado lo anterior, se deduce que el medio f´ısico es totalmente incompatible y mucho m´as complicado que 802.3.

8

13

15

10

0

Figura 27: Organizaci´on F´ısica y L´ogica de una Red Token Bus.

Subcapa MAC El funcionamiento b´asico del protocolo de nivel MAC es el siguiente: cada estaci´on conoce la direcci´on de las estaciones que est´an a la izquierda y derecha suya. Al inicializarse el anillo el nodo con la direcci´on m´as alta puede enviar el primer frame, enviando el token a la estaci´on vecina que tenga la direcci´on de nodo siguiente. Luego, el token pasa de nodo en nodo desde las direcciones altas a las bajas y el funcionamiento es similar al del protocolo token passing. 64

El orden f´ısico que tengan la estaciones no importa para nada en el funcionamiento y las estaciones f´ısicamente conectadas al bus no necesariamente deben estar conectadas al anillo l´ogico (ver Figura 27). El protocolo define adem´as clases de prioridades de tr´afico: 0, 2, 4 y 6, siendo la 0 la m´as baja. Al llegar el token a la estaci´on, se verifica si la prioridad 6 tiene datos para transmitir, si es as´ı los env´ıa y pasa despu´es a la prioridad 4, sino pasa inmediatamente a la siguiente prioridad, situaci´on que sigue hasta llegar al nivel 0 o bien hasta que haya expirado el token holding time. El protocolo adem´as provee mecanismos para hacer uso del tiempo por parte de las prioridades inferiores si es que las superiores no tienen nada que transmitir. Adem´as, se puede permitir reservar una cierta fracci´on del tiempo al tr´afico de prioridad 6, lo que implica una reservaci´on de ancho de banda para este tipo de tr´afico, que permitir´a el mejor tratamiento de tr´afico en tiempo real. 1 B 1 B 1 B 2-6 B P D F Dir. r I C Destino e

2-6 B

0-8182 B

4B

1B

Dir. Fuente

Datos

CRC

D T

Figura 28: Formato del Frame Token Bus.

El formato del frame token bus se observa en la Figura 28 y el detalle de los campos es el siguiente: Pre´ ambulo. 1 Byte que es utilizado para sincronizar el clock del receptor. Delimitador de Inicio. 1 Byte utilizado para demarcar el inicio del frame. Frame de Control. 1 Byte que distingue al frame entre un frame de datos o de control. Si es de datos lleva el nivel de prioridad y puede llevar la solicitud de acknowledge positivo o negativo para el destino (por ejemplo, un frame de datos tiene la forma 01MMMPPP, donde MMM indicar´a la confirmaci´on y PPP la prioridad). Caso contrario, indica el tipo de frame de control que representa (en este caso el frame tiene la forma 00CCCCCC; 00000000 significa Claim Token). Direcci´ on Destino. 6 Bytes, que indican la direcci´on del nodo destino. Direcci´ on Origen. 6 Bytes, que indican la direcci´on del nodo fuente. Datos. M´aximo 8182 Bytes, campo que encapsula los datos del nivel superior. 65

CRC. 4 Bytes que corresponden a una suma de verificaci´on para asegurar que el frame lleg´o en buen estado. Delimitador de T´ ermino. 1 Byte utilizado para demarcar el final del frame. Mantenimiento del Anillo Una vez que el anillo entr´o en funcionamiento cada nodo sabe qui´en es su predecesor y su sucesor. Peri´odicamente, el nodo que tiene el token env´ıa un frame de control, especial llamado Solicit Successor que permite agregar nuevas estaciones al anillo, siempre que se encuentren en el rango del poseedor del token. Si s´olo un nodo desea entrar, hace ingreso al anillo y ser´a el siguiente poseedor del token. Si existe m´as de uno, entonces se producir´a una colisi´on, y el poseedor del token enviar´a un frame Resolve Contention que permitir´a arbitrar la colisi´on de una manera similar a como funciona el protocolo de cuenta regresiva binaria. Se debe notar que no existe garant´ıa de cu´al ser´a el tiempo m´aximo que debe esperar un nodo para poder hacer ingreso a la red, pero en la pr´actica no debiera ser m´as que algunos segundos. Si un nodo desea dejar el anillo env´ıa un frame Set Successor a su predecesor con la direcci´on de su sucesor y entonces queda fuera del anillo. Para inicializar el anillo el primer nodo que se enciende env´ıa el frame de control Claim Token, de no recibir respuesta, crea el token y el anillo, enviando peri´odicamente frames Solicit Successor. Nuevamente, si m´as de un nodo env´ıa un frame Claim Token se produce una colisi´on y el problema se resuelve de la misma forma que antes. El problema de que un nodo falle cuando deba enviar el token se soluciona haciendo que el predecesor quede escuchando si su sucesor envi´o alg´ un frame, de no ser as´ı, vuelve a enviar el token. Si el problema persiste entonces env´ıa un frame Who Follows con la direcci´on de su sucesor. El frame, al ser visto por el sucesor de la estaci´on que fall´o, env´ıa un Set Successor y el anillo se reestablece. Si fallara tambi´en el nodo que sigue a la estaci´on que originalmente fall´o, entonces se env´ıa un frame Solicit Successor 2 para ver si alg´ un nodo m´as est´a operativo. Esto puede producir colisiones, las que se resolver´an de la manera tradicional, reestableciendo el anillo. Si el problema se presenta con el nodo que tiene el token y ´este se pierde, entonces pasado un cierto time out, los nodos restantes utilizan el algoritmo de inicializaci´on del anillo.

2.9.

Token Ring/IEEE 802.5

Despu´es de la propuesta de Ethernet y de Token Bus, el comit´e IEEE 802.3 recibi´o otra propuesta, esta vez de IBM que present´o una red con topolog´ıa f´ısica de anillo y protocolo 66

MAC token passing que se denominaba Token Ring. El comit´e, viendo que no ser´ıa posible elaborar un u ´nico est´andar y considerando que el apoyo de la industria a cada propuesta era demasiado importante como para descartar cualquiera de ellas, opt´o por aceptar las tres y crear un subcomit´e para cada una de ellas: 802.3 para CSMA/CD (Ethernet), 802.4 para Token Bus y 802.5 para Token Ring. Medio F´ısico El est´andar define dos velocidades de operaci´on: 4 y 16 Mbps. El cableado utilizado es STP o UTP categor´ıa 3 o superior para 4 Mbps, y STP para 16 Mbps. La se˜ nal se representa usando codificaci´on Manchester diferencial, que emplea la presencia o ausencia de transici´on entre dos voltajes para indicar un 0 o un 1, respectivamente. Requiere un equipo m´as caro y complejo que la codificaci´on Manchester, pero presenta mayor inmunidad al ruido y est´a mejor adaptada al uso de cable pares, ya que no tiene problemas de polaridad invertida. El gran problema de la topolog´ıa anillo es que la rotura de ´este en un punto impide la comunicaci´on. Para evitar el problema, lo que se hace es colapsar el anillo en un hub o concentrador, tambi´en llamado centro de cableado, al cual se conectan los cables de entrada y salida de cada estaci´on. El cableado sigue siendo l´ogicamente un anillo, a´ un cuando f´ısicamente sea una estrella. En el concentrador se instalan rel´es de bypass alimentados por el nodo correspondiente, de forma que si la conexi´on de ´esta falla, el rel´e cortocircuita el enlace correspondiente restaurando el anillo. Tambi´en es posible constituir anillos dobles para obtener mayor confiabilidad, ya que en caso de corte en un punto, el doble anillo puede cerrarse sobre s´ı mismo solucionando el problema. Cada nodo que se agrega a la red a˜ nade una cierta cantidad de jitter en la retransmisi´on de la informaci´on, situaci´on que limita el n´ umero m´aximo de estaciones que pueden estar presentes en una red Token Ring. En redes de 4 Mbps con cable UTP el m´aximo es de 72, mientras que en las de 16 Mbps con cable STP el m´aximo es de 250 estaciones. Subcapa MAC Las redes token ring funcionan b´asicamente de la siguiente forma: si ning´ un host desea transmitir, todos est´an en modo escucha y el token, que es un frame de 3 bytes, va pasando de un host a otro indefinidamente. Cuando alg´ un nodo desea transmitir debe esperar a que pase por ´el el token. En ese momento, se apodera de ´este, pasa a modo transmisi´on y env´ıa el frame al siguiente nodo. Todos los dem´as hosts del anillo, incluido el destino, siguen en modo escucha, retransmitiendo el frame recibido hacia el siguiente nodo. El host destino, adem´as de 67

retransmitirlo, retiene una copia del frame. El nodo transmisor puede que restaure el token en el anillo inmediatamente, o puede que espere hasta recibir su frame para restaurar el token. 1B1B1B D C D I A T a) 1B1B1B D C I A

F C

2-6 B

2-6 B

Sin Límite

4B

Dir. Destino

Dir. Fuente

Datos

CRC

1B1B D T

S F

b)

Figura 29: Formato del a) Token de Token Ring b) Frame Token Ring.

El formato del frame token bus se observa en la Figura 29 y el detalle de los campos es el siguiente: Delimitador de Inicio. 1 Byte utilizado para demarcar el inicio del frame. Control de Acceso. 1 Byte que contiene bits especiales: tres de prioridad, el del token, el de monitor y tres de reserva. Su forma es PPPTMRRR. Frame de Control. 1 Byte que distingue al frame entre un frame de datos o de control. Direcci´ on Destino. 6 Bytes que indican la direcci´on del nodo destino. Direcci´ on Origen. 6 Bytes que indican la direcci´on del nodo fuente. Datos. campo que encapsula los datos del nivel superior, limitado en tama˜ no por el Token Holding Time. CRC. 4 Bytes que corresponden a una suma de verificaci´on para asegurar que el frame lleg´o en buen estado. Delimitador de T´ ermino. 1 Byte que marca el final del frame. Los seis primeros bits forman una secuencia inv´alida en la codificaci´on Manchester diferencial. El s´eptimo se utiliza para indicar el u ´ltimo frame cuando lo que se transmite es una secuencia de frames. El octavo bit indica si se ha producido un error en la transmisi´on del frame entre dos nodos. Si alg´ un nodo detecta un error en el frame pondr´a en 1 este bit. Esto integra un mecanismo intr´ınseco de detecci´on de errores en la transmisi´on. 68

Estado del Frame. 1 Byte que contiene dos bits especiales, el A y el C. Al llegar un frame al destino, ´este coloca el bit A en uno y si el nodo copia el frame coloca el bit C en uno. Con esto, el nodo emisor al recibir su frame tiene las siguientes opciones en los bits AC: 00 destino no presente, 10 destino presente y frame no aceptado, 11 destino presente y frame copiado. Con esto, el protocolo incorpora un mecanismo autom´atico de acuse de recibo. La estructura de un token es una versi´on simplificada de un frame. Contiene u ´nicamente los campos DI, CA y DT. En el campo CA el bit de token est´a siempre puesto a 0. En el campo DT los dos u ´ltimos bits est´an siempre a 0. El campo CA dispone de tres bits de prioridad que funcionan de la siguiente manera: cuando un host desea transmitir un frame con prioridad n debe esperar a que pase por ´el un token de prioridad menor o igual que n. Adem´as, los hosts pueden aprovechar un frame en tr´ansito para solicitar al emisor un token de una determinada prioridad. Un host s´olo puede utilizar los bits de reserva si ´estos no contienen ya una petici´on de mayor prioridad. Cuando el frame de datos vuelve a su emisor, ´este emitir´a un token de la prioridad solicitada, que ser´a la m´as alta que hubiera pendiente en el anillo. En el caso de funcionar con Early Token Release este mecanismo de prioridad queda parcialmente deshabilitado debido a que el emisor ha de restaurar el token antes de haber recibido las solicitudes de reserva. Mantenimiento del Anillo En toda red Token Ring existe un nodo denominado monitor que se ocupa de resolver los problemas y garantizar el normal funcionamiento del protocolo. En caso de problemas, el monitor restaurar´a un token en el anillo para que el tr´afico pueda seguir circulando normalmente. Adem´as, cualquier host de la red est´a capacitado para actuar como monitor en caso necesario. Cuando un nodo se une a la red, escucha la red en busca de tokens o frames de datos. Si no detecta actividad emite un frame Claim Token. Si existe ya un monitor, responder´a con un token a la petici´on. Si no, el nodo reci´en incorporado a la red recibir´a su propio claim token, momento en el cual pasar´a a constituirse en monitor. El monitor cumple un papel muy importante en el funcionamiento de la red, pues es el encargado de resolver diversos problemas de operaci´on. Por ejemplo, se entiende por frame hu´erfano a aquel frame enviado por una estaci´on que posteriormente falla y no lo saca del anillo. El monitor es el encargado de darse cuenta de la situaci´on y eliminar el frame, utilizando para ello el bit monitor, pues si un frame pasa dos veces por el monitor con el bit seteado 69

quiere decir que corresponde a un frame hu´erfano. Adem´as, el monitor tiene un timer asociado que permite determinar la falta de tokens en la red. El monitor se ocupa tambi´en de facilitar los buffers necesarios para garantizar que en todo momento la red puede albergar los 24 bits del token, pues para que el protocolo pueda funcionar es necesario que el tama˜ no de la red permita mantener el token circulando en todo momento. Una funci´on que no es realizada por el monitor es la de detectar rupturas del anillo. Si un nodo detecta que uno o m´as de sus vecinos est´a abajo, transmite una se˜ nal Beacon con la direcci´on de los nodos que fallan. Una vez que esta se propaga, los nodos se sacan del anillo con los rel´es de bypass.

2.10.

100VGAnyLAN/IEEE 802.12

100VGAnyLAN es un est´andar LAN que pretende ofrecer una alta velocidad con un medio compartido sustituyendo los protocolos m´as lentos, pero utilizando los medios existentes y siendo compatible con ellos. 100VGAnyLAN est´a formada principalmente por nodos finales y repetidores. Los nodos finales son normalmente computadores, bridges, routers, switches o servidores. Ellos son los que transmiten y reciben datos a trav´es del repetidor. Los repetidores son el centro conceptual y f´ısico de la red. Sirven de controladores centrales y manejan el acceso a la red realizando continuamente tests. Cada repetidor tiene un puerto de conexi´on especial a trav´es del cual se puede conectar con otros repetidores en cascada. Un repetidor debe ser configurado para manejar formatos de frame token ring o IEEE 802.3. Todos los repetidores de un mismo segmento deben usar el mismo formato de frame. Medio F´ısico La topologia de 100VGAnyLAN es estrella, pero no es necesario que los nodos finales est´en conectados directamente al nodo central, sino que pueden conectarse a trav´es de nodos intermedios formando un ´arbol. La especificaci´on de IEEE establece cable UTP categor´ıa 3 ´o 5, STP y fibra ´optica. La velocidad de operaci´on es de 100 Mbps y la codificaci´on es 5B6B. Subcapa MAC La transmisi´on de frames consiste en una secuencia en la que el emisor realiza una petici´on y la contraparte contesta la petici´on. La secuencia de transmisi´on sigue los siguientes pasos:

70

1. Si un nodo tiene un frames para transmitir emite una se˜ nal de control Request que puede tener una prioridad normal o alta. Si no es el caso, el nodo transmite la se˜ nal de control IdleUp. 2. El repetidor sondea todos los puertos para determinar que hosts han pedido enviar un frame y con que prioridad se ha realizado la petici´on. 3. El repetidor selecciona el nodo con petici´on de prioridad alta pendiente, de acuerdo al puerto al que est´a conectado. Lo mismo se hace para las prioridades bajas. La selecci´on causa que el puerto elegido reciba la se˜ nal Grant y la transmisi´on del frame comienza cuando el nodo detecta la se˜ nal de permiso. 4. El repetidor env´ıa una se˜ nal Incoming a todos los otros nodos finales, avis´andoles de la posible llegada de un frame. El repetidor decodifica la direcci´on de destino del frame transmitido en cuanto la recibe. 5. Cuando un nodo final recibe la se˜ nal de llegada, se prepara para recibir un frame interrumpiendo la transmisi´on de peticiones y escuchando en el medio. 6. Una vez que el repetidor ha decodificado la direcci´on destino, el dato es enviado al nodo o nodos finales correspondientes. Los nodos que no reciben el frame, reciben la se˜ nal de control IdleDown del repetidor para que vuelvan a lo que estuvieran haciendo. 7. Cuando un nodo final recibe un frame de datos, vuelve a su estado anterior a la recepci´on, enviando una se˜ nal IdleUp o haciendo una petici´on para enviar un frame. 2B3B 6B P I Dir. r F Destino e

6B Dir. Fuente

2B

2B

Pet Config Config Con

594-675 B

4B

3B

Datos

CRC

F F

Figura 30: Formato del Frame 100VGAnyLAN.

100VGAnyLAN est´a dise˜ nada para operar de forma compatible con los formatos de frame Ethernet y Token Ring. Esto significa que el software y los protocolos sobre el nivel de enlace s´olo necesitan saber que est´an operando en una red Ethernet o Token Ring. La descripci´on del frame es la siguiente (ver Figura 30):

71

Inicio del Frame. 2 Bytes de delimitador de inicio de frame que permite detectar cuando se est´e enviando un frame. Pre´ ambulo: permite detectar donde empiezan los datos Direcci´ on Destino. 6 Bytes que indican la direcci´on del nodo destino. Direcci´ on Origen. 6 Bytes que indican la direcci´on del nodo fuente. Petici´ on de Configuraci´ on. 2 Bytes, permiten al nodo informar al repetidor sobre s´ı mismo y pedir una configuraci´on de su puerto. El bit repetidor de este campo informa al repetidor si se trata de un nodo final o de otro repetidor. Configuraci´ on Concedida. 2 Bytes, permiten al repetidor responder a la petici´on de configuraci´on con la configuraci´on asignada. Este campo se pone a cero por el nodo final y el repetidor asigna los valores apropiados. Datos. 594 a 675 Bytes, campo que encapsula los datos del nivel superior. CRC. 4 Bytes que corresponden a una suma de verificaci´on para asegurar que el frame lleg´o en buen estado. Final del Frame. 3 Bytes, permite finalizar la recepci´on del frame, y enviar los datos al nivel superior. La detecci´on en el delimitador de una secuencia Invalid Packet Marker informa de un error. Prueba del Enlace La prueba de enlace tiene diferentes prop´ositos, como la verificaci´on de la calidad del cable para la transmisi´on de datos, ayudar al receptor a adaptarse al enlace estableciendo la direcci´on MAC del nodo final en la tabla del repetidor y establecer la configuraci´on del enlace para frames Ethernet o Token Ring y determinar si se trata de un nodo final o repetidor. La prueba de enlace se efect´ ua cada vez que se establece un enlace, como al encender el equipo y al conectar el cable o cuando ocurren algunos errores. La prueba de enlace siempre es iniciada por la entidad inferior al repetidor, que es quien desea conectarse a la red. La prueba incluye la transmisi´on de frames de prueba entre la entidad inferior y el repetidor. Una vez que la entidad inferior se ha conectado a la red, el repetidor a˜ nade la direcci´on del nodo a su tabla interna. Si la entidad inferior es tambi´en un repetidor, todos los frames que 72

reciba el repetidor superior ser´an transmitidos a esa entidad inferior. Si el repetidor superior tiene repetidores conectados o est´a conectado a un repetidor superior, todos los frames de la entidad inferior son enviadas a esos repetidores. Si el repetidor tiene la direcci´on destino en su tabla interna, el frame es dirigido al nodo especifico. En caso de que el repetidor reciba un frame de su repetidor superior, no dirigido a ninguno de sus nodos finales, el frame se descarta.

Puerto 1 2 3 4 5 6 7 8 tiempo Petición de Alta Prioridad

Frame de Alta Prioridad

Petición de Baja Prioridad

Frame de Baja Prioridad

Figura 31: Ejemplo de Operaci´on de una red 100VGAnyLAN.

Operaci´ on La Figura 31 muestra como opera un hub 100VGAnyLAN ante las peticiones de alta y baja prioridad emitidas por los nodos. El hub tiene dos punteros, uno para cada prioridad, los cuales se incrementan para ir atendiendo las peticiones utilizando un esquema round robin. Inicialmente el hub coloca los punteros en 1 y comienza a escanear sus puertas, encontrando una petici´on de baja prioridad en el puerto 2, permitiendo que se env´ıe el frame y actualizando el puntero de baja prioridad a 3. Una vez completada la transferencia el hub vuelve a escanear sus puertos y descubre dos peticiones de alta prioridad desde los puertos 5 y del 1. Comienza atendi´endose el puerto 1 pues el puntero de alta prioridad estaba ah´ı, y luego se actualiza a 2 73

para atender la siguiente petici´on. Mientras se enviaba el frame del puerto 1, aparecieron dos peticiones de baja prioridad (puertos 2 y 7), las cuales se atender´an luego de las peticiones de alta prioridad. A continuaci´on, se procesa la petici´on del puerto 5 y se actualiza el puntero de alta prioridad a 6, y conjuntamente se reciben dos peticiones m´as de baja prioridad, desde los puertos 3 y 6. Una vez finalizado el env´ıo del frame de prioridad alta del puerto 5 se comienzan a procesar la peticiones de baja prioridad, partiendo por la petici´on del puerto 3, ya que el puntero estaba en ese valor, y se actualizar´a entonces a 4. Luego se procede con la petici´on 6 y a continuaci´on con la 7 actualizando el puntero de baja prioridad a 8. Mientras tanto, una petici´on de baja prioridad llega desde el puerto 8 seguida de una de alta prioridad del puerto 1, la cual deber´a ser atendida primero. Despu´es de transmitido el frame del puerto 7 se transmite el de alta prioridad del puerto 1 y se actualiza el puntero respectivo a 2. No habiendo m´as peticiones de alta prioridad, se contin´ ua con las de baja, enviando el frame del puerto 8 y actualizando el puntero a 1, para finalmente procesar el frame del puerto 2, que hab´ıa quedado pendiente en las peticiones, y el puntero de baja prioridad quedar´a entonces en 3.

2.11.

FDDI

FDDI funciona a 100 Mbps y su est´andar fue definido inicialmente por ANSI y m´as tarde adoptado por ISO. An´alogamente a los otros est´andares, el documento describe la capa f´ısica y la subcapa MAC. Para la parte LLC se utiliza el est´andar IEEE 802.2. Las caracter´ısticas de velocidad, distancia y confiabilidad de FDDI la convirtieron durante alg´ un tiempo en la red ideal para ser utilizada como backbone que concentre las LANs de una gran organizaci´on. FDDI tiene muchos elementos comunes con Token Ring, y en cierta medida puede considerarse una evoluci´on de aquella tecnolog´ıa. La topolog´ıa es de doble anillo para aumentar la seguridad, no la velocidad. En condiciones normales un token gira por cada anillo en sentido opuesto. Las estaciones pueden ser SAS (Single Attach Station) si est´an enchufadas a un anillo u ´nicamente, o DAS (Dual Attach Station) si lo est´an a ambos. Si se produce un corte en los anillos las estaciones DAS m´as pr´oximas a cada lado del corte unen entre s´ı ambos anillos, con lo que se crea un anillo de mayor longitud que permite mantener conectados todos los hosts. En el caso de producirse un segundo corte en otro punto del anillo se crean dos anillos aislados, cada uno de los cuales puede seguir funcionando. Las interfases DAS son m´as caras que las SAS, pero dan una mayor tolerancia a fallas al permitir cerrar el anillo.

74

Hasta 1996 FDDI era la principal tecnolog´ıa de red de alta velocidad. Sin embargo, su grado de implantaci´on siempre ha sido escaso. La principal raz´on de esto ha sido su elevado costo comparado con las LANs tradicionales, como Ethernet o Token Ring. Hoy en d´ıa ha sido completamente superada por Fast Ethernet y Gigabit Ethernet. Medio F´ısico El medio f´ısico de transmisi´on es fibra ´optica multimodo o UTP Categor´ıa 5. En este u ´ltimo caso se utiliza una topolog´ıa f´ısica similar a la de 10Base-T, con los nodos conectados a hubs. La distancia m´axima del nodo al hub es de 100 metros. Tambi´en es posible utilizar hubs para la conexi´on de nodos por fibra ´optica. A diferencia de Token Ring, no se utiliza codificaci´on Manchester diferencial, sino 4B5B.

1B1B1B D I 1B1B D I

F C

2-6 B

2-6 B

Dir. Destino

Dir. Fuente

F D C T a) Hasta 4500 B

4B

Datos

CRC

1B1B D T

S F

b)

Figura 32: Formato del a) Token FDDI b) Frame FDDI.

Subcapa MAC La estructura de un frame y token FDDI es muy similar a la de Token Ring (ver Figura 32). La longitud m´axima del campo datos puede ser de hasta 4500 bytes. El protocolo MAC de FDDI es tambi´en muy parecido al de Token Ring. La diferencia m´as notable es que en FDDI siempre se funciona con el principio de Early Token Release. Existe tambi´en un token-holding timer que establece el tiempo m´aximo que una estaci´on puede transmitir de una vez. Este par´ametro tiene importantes consecuencias en el rendimiento de la red. El valor por defecto de 4 ms es adecuado en la mayor´ıa de las situaciones, excepto en las redes muy grandes (m´as de 20 Kms) en que es conveniente aumentarlo.

75

Subcapa LLC

Capa Enlace

Subcapa MAC

Capa Física

FHSS

IR

DSSS

Modelo OSI

Figura 33: Arquitectura del protocolo IEEE 802.11.

2.12.

WLAN IEEE 802.11

El IEEE en 1997 aprob´o el est´andar 802.11 que define los niveles f´ısico y la subcapa MAC para las transmisiones inal´ambricas en una LAN (Figura 33). El est´andar define el protocolo de comunicaci´on para dos tipos de redes: las Adhoc, que son aquellas formadas por m´ ultiples puntos inal´ambricos dentro de un ´area de cobertura donde todos los nodos tienen el mismo nivel jer´arquico, y las redes Cliente/Servidor, que son aquellas que usan un punto de acceso (AP) que controlan la asignaci´on los de tiempos transmisi´on para cada estaci´on de la red, generando celdas de cobertura (llamadas BSS) por cada AP, y permitiendo a los usuarios moverse entre la o las celdas. Adem´as de esto, los AP permiten que la red inal´ambrica se conecte con un backbone, ya sea cableado o inal´ambrico, que recibe el nombre de Sistema de Distribuci´on (DS). La Figura 34 muestra los componentes antes descritos en una red del tipo Cliente/Servidor. DS AP

AP

BSS BSS

Figura 34: Componentes de la arquitectura IEEE 802.11.

Medio F´ısico El medio f´ısico define dos m´etodos de transmisi´on usando Radio Frecuencia y uno que utiliza el Infrarrojo. Las bandas de RF se eligieron de tal forma que no se necesite permiso 76

de la autoridad para poder utilizarla, operando en la banda de los 2.4 GHz utilizando unos 83 MHz desde 2.4 a 2.483 GHz empleando modulaci´on de espectro disperso o extendido. Las dos alternativas son: Frequency Hopping Spread Spectrum (FHSS) y Direct Sequence Spread Spectrum (DSSS). DSSS utiliza modulaci´on DBPSK y DQPSK mientras que FHSS usa 2GFSK y 4GFSK. El nivel f´ısico establece un bit rate de 1 Mbps para FHSS y de 1 y 2 Mbps para DSSS. La elecci´on de uno u otro sistema depender´a del tipo de aplicaci´on y del ambiente de trabajo en que se encuentre la red. Como aspecto pr´actico se puede comentar que existen diferentes frecuencias de uso aprobadas para USA, Europa y Jap´on, por lo que los productos deben cumplir con los requerimientos establecidos en el pa´ıs donde operar´a la red. En el caso de la especificaci´on para infrarrojos, ´estos operan en la banda de 850 a 950 nM, la modulaci´on utilizada es hecha usando modulaci´on PPM de 4 ´o 16 niveles. ra esta especificaci´on, el nivel f´ısico establece bit rates de 1 y 2 Mbps. En 1999 el grupo de trabajo 802.11 aprob´o dos extensiones al est´andar: IEEE 802.11a que usando la banda de 5 GHz, modulaci´on OFDM llega a bit rates de 6, 9, 12, 18, 24, 36, 48 y 54 Mbps; y el IEEE 802.11b que mantiene la banda de 2.4 GHz, soportando una velocidad de hasta 11 Mbps modulando con CCK. Subcapa MAC En al subcapa MAC IEEE 802.11 utiliza como protocolo de acceso al medio lo que se denomin´o Funci´ on de Coordinaci´ on Distribuida que es b´asicamente CSMA/CA en conjunto con un esquema de acknowledge. Cuando un nodo desea transmitir sensa el medio si est´a ocupado espera un tiempo aleatorio utilizando un algoritmo de backoff. En el caso de estar libre durante un peque˜ no intervalo de tiempo llamado DIFS, entonces el nodo est´a habilitado para transmitir. El receptor, al recibir el frame revisa el CRC y en caso de estar correcto devuelve un ACK al emisor. En caso de que el emisor no reciba el ACK, entonces ´este retransmitir´a el frame hasta recibirlo, o hasta que haya superado un cierto n´ umero de intentos fallidos. Adem´as del DIFS existe otros tiempos asociados, por ejemplo el SIFS que es el tiempo usado para separar las transmisiones de una misma conexi´on, por ejemplo cuando se env´ıa un frame y se espera el ACK. Este tiempo siempre es menor que el DIFS. En realidad DIF S = SIF S + t donde t corresponde a un slot de tiempo que son 128 µs. Para disminuir la probabilidad de colisiones, producto de que dos nodos no puedan escucharse, el est´andar implementa un mecanismo de sensado virtual de portadora. Este m´etodo consiste en transmitir antes del frame un RTS y recibir desde el receptor un frame CTS, que 77

DIFS Orig

RTS

Dato SIFS

SIFS Dest

SIFS

CTS

Ack NAV RTS

DIFS

NAV CTS

Otro

Posponer Envío tiempo

Figura 35: Transferencia en una WLAN y el NAV de uno de los nodos vecinos.

tiene como informaci´on el tiempo que tomar´a la transmisi´on en efectuarse. Dado que los nodos adyacentes al emisor y receptor escuchar´an el RTS y/o el CTS, quienes escuchen al menos uno de ellos, usar´an esta informaci´on (llamada vector de asignaci´on de red o NAV) en conjunto con el sensado f´ısico del medio para realizar la transmisi´on. Es decir, si el sensar el canal o el NAV indican que el canal est´a ocupado, entonces no se transmite un frame. La Figura 35 muestra los tiempos DIFS y SIFS, el NAV y los frames RTS, CTS, ACK y los Datos enviados por emisor y receptor, adem´as de la situaci´on que tiene lugar en un tercer nodo que no participa del intercambio de informaci´on. Adem´as de la funci´on de acceso al medio y del control de flujo provisto, la subcapa MAC de IEEE 802.11 cumple la funci´on de segmentaci´on y reensamblaje de frames. Debido a que IEEE 802.11 funcionar´a en conjunto con las Ethernet tradicionales, no tiene sentido utilizar una WLAN que no sea capaz de manejar frames de hast 1518 bytes. Pero, dado que el medio f´ısico de una WLAN es bastante propenso a errores, resulta conveniente manejar frames m´as peque˜ nos para disminuir el efecto de las sucesivas retransmisiones. Por esta raz´on, el comit´e lleg´o a un compromiso, implementando segmentaci´on de la carga u ´til de un frame de nivel de enlace tradicional, en varios frames m´as peque˜ nos, los que tienen cada uno un encabezado de nivel 2 y que deben ser confirmados positivamente para poder enviar el siguiente fragmento. En el receptor se lleva a cabo la funci´on inversa y se vuelve a ensamblar el dato. La Figura 36a) muestra el formato de un frame de datos IEEE 802.11. La descripci´on de los campos del formato general es la siguiente: Pre´ ambulo. 96 bits de sincronizaci´on, de los cuales los primeros 80 son una serie de 1 y 0 alternados y los u ´ltimos 16 delimitan el inicio del frame con el pattern 0000 1100 1011 78

Pre 2B 2B FC D/ID 2b Versión

PLCP 6B Dir 1 2b Tipo

6B Dir 2 4b Subtipo

MAC Data a) 6B 2B 6B 0-2312 B 4B Dir 3 SC Dir 4 Datos CRC b) 1b 1b 1b 1b 1b 1b 1b 1b tDS fDS MF Re PM MD Wep Or c)

Figura 36: Formato de un Frame de Datos IEEE 802.11 a) Formato General b) Campo MAC Header c) Campo Frame Control.

1101. PLCP. encabezado que siempre es transmitido a 1 Mbps y contiene informaci´on que sirve al nivel f´ısico para decodificar el frame. Contiene el largo del campo de datos adem´as de un CRC para el encabezado. MAC Data. campo con la informaci´on t´ıpica del nivel de enlace. Es detallado a continuaci´on. La Figura 36c) ilustra el detalle del campo Frame Control que corresponde al primer campo del MAC Data: Versi´ on. 2 bits para indicar la versi´on del protocolo. Actualmente el valor que se coloca es 00. Tipo. 2 bits que en conjunto con el campo Subtipo definen si el frame es de control, de datos, de administraci´on o reservado. Subtipo. 4 bits que en conjunto con el campo Tipo definen si el frame es de control, de datos, de administraci´on o reservado. toDS. 1 bit que es puesto en 1 cuando se desea que el frame se reenv´ıe usando un AP hacia el DS. fromDS. 1 bit es puesto en 1 cuando el frame fue enviado usando un AP. More Fragments. 1 bit que indica que el frame se ha dividido y existen m´as fragmentos a continuaci´on.

79

Retry. 1 bit que inca que el frame es una retransmisi´on de alg´ un frame anterior. Resulta u ´til por ejemplo cuando se pierde un ACK. Power Management. 1 bit que establece el modo de operaci´on una vez finalizada la transmisi´on de un frame. Los estados pueden ser ahorro de energ´ıa o activo. Mode Data. 1 bit usado para indicar al AP que existen m´as frames almacenados en ´el. WEP. 1 bit para indicar que el campo de datos est´a encriptado. Order. 1 bit que indica que los frames fueron enviados en usando la clase de servicio StrictlyOrdered. En la Figura 36b) se observa el desglose del campo MAC Data del frame de datos IEEE 802.11. Frame Control. 2 Bytes usados para m´ ultiples funciones de control. Se detallaron previamente. Duration/ID. 2 Bytes que cumplen doble funci´on. Si se trata de un frame de control para el ahorro de energ´ıa, entonces el campo indica el identificador de la estaci´on. Si es otro tipo de frame, entonces indica el valor usado para el c´alculo del NAV. Direcci´ on 1. 6 Bytes. Corresponde siempre a la direcci´on de destino. Si el bit toDS est´a activo corresponde entonces a la direcci´on del AP caso contrario corresponde al usuario wireless destino. (Ver Tabla 5). Direcci´ on 2. 6 Bytes. Corresponde siempre a la direcci´on origen. Si el bit fromDS est´a activo corresponde entonces a la direcci´on del AP caso contrario corresponde al usuario wireless origen. (Ver Tabla 5). Direcci´ on 3. 6 Bytes. La mayor cantidad de veces corresponde a la direcci´on “faltante”. Si el frame tiene el bit fromDS en 1, entonces corresponde a la direcci´on fuente original. Si el frame tiene el bit toDS en 1, entonces corresponde a la direcci´on destino. (Ver Tabla 5). Sequence Control. 2 Bytes que permiten numerar los frames y los segmentos en el caso en que se divida un frame en varios fragmentos.

80

´ Direcci´ on 4. 6 Bytes. Util en el caso especial en que se use un Wireless DS y el frame deba transferirse desde un AP a otro (similar a un esquema de telefon´ıa celular) que corresponde al caso en que los bit toDS y fromDS est´en ambos en 1. En este caso, los campos Direcci´on 3 y Direcci´on 4 contienen las direcciones fuente y origen (de las m´aquinas). (Ver Tabla 5). Datos. campo que encapsula los datos del nivel superior. CRC. 4 Bytes que corresponden a una suma de verificaci´on para asegurar que el frame lleg´o en buen estado.

Tabla 5: Resumen del uso de los campos de direcciones en un frame IEEE 802.11 toDS fromDS Direcci´on 1 Direcci´on 2 Direcci´on 3 Direcci´on 4 0

0

DA

SA

BSSID

N/A

0

1

DA

BSSID

SA

N/A

1

0

BSSID

SA

DA

N/A

1

1

RA

TA

DA

SA

La Figura 37 muestra el formato de la parte MAC Data de los frames RTS (parte a)), CTS (parte b)) y ACK (parte c)). Para el frame RTS el campo RA es la estaci´on destino del frame, TA es la estaci´on que origina el frame y el campo Duration/ID es el valor en microsegundos del tiempo que demorar´a la transmisi´on total del frame. El frame CTS es id´entico al anterior, salvo que ahora el campo TA no existe y el campo RA contiene la direcci´on del frame que envi´o el RTS. El frame ACK es id´entico al CTS, pero ahora el campo el campo RA contiene la direcci´on del frame que envi´o el CTS. En este caso, si el bit More Fragments est´a en 0, el campo Duration/ID tiene valor 0, caso contrario, ´este tendr´a el valor de tiempo que tome transmitir el siguiente frame de datos. Funciones M´ oviles y de Seguridad Uni´ on al BSS. Cuando un nodo desea unirse al BSS necesita obtener informaci´on de sincronismo desde el AP (o desde otra estaci´on en el caso de las redes Adhoc). Para esto, puede usar el modo de b´ usqueda pasivo (que consiste en esperar hasta recibir, desde el AP, un frame especial de sincronizaci´on emitido peri´odicamente, llamado Beacon) o el modo de b´ usqueda activo (que es enviar frames de b´ usqueda llamados Probe Request y esperar recibir 81

2B 2B FC D/ID 2B 2B FC D/ID 2B 2B FC D/ID

6B RA a) 6B RA b) 6B RA c)

6B TA

4B CRC

4B CRC 4B CRC

Figura 37: Formato de los Frames de Control IEEE 802.11 a) RTS b) CTS c) ACK.

un Probe Response desde el AP). Una vez que el nodo ha encontrado el AP, sigue un proceso de autentificaci´on en el cual se produce el intercambian passwords. Una vez finalizado esto se pasa al proceso de asociaci´on, en el cual se produce intercambio de informaci´on sobre el BSS, nodos, etc. Una vez que se ha completado este proceso, el nodo puede intercambiar datos con la red. Roaming. Es el proceso que permite a un usuario m´ovil pasar desde un BSS a otro sin perder la conexi´on. Esta situaci´on no es definida por el est´andar, pero s´ı se establecen las herramientas b´asicas para ello: modo de b´ usqueda activo/pasivo y reasociaci´on a un BSS. Sincronismo. Esto se lleva a cabo haciendo que todos los nodos est´en a la misma hora. Para ello, el AP env´ıa peri´odicamente frames Beacon en los que se informa de la hora del AP. Estos frames son recolectados por los nodos quienes actualizan sus relojes. Seguridad. Dos han sido los aspectos claves a considerar: evitar el libre acceso a los recursos de la red y evitar que se “escuche” las transmisiones por entes no deseados. El primer aspecto se soluciona con el m´etodo de autentificaci´on usado para acceder al BSS, lo segundo se soluciona usando WEP (Wireless Encription Protocol) que es un protocolo de encriptaci´on basado en el algoritmo RC4, que es bastante contra rupturas de clave y adem´as es autosincronizante.

2.13.

Subcapa de Control de Enlace L´ ogico

La subcapa MAC forma la mitad inferior de la capa de enlace en las redes broadcast. Sobre ella se encuentra la subcapa LLC que corresponde en funciones a la capa de enlace de las l´ıneas punto a punto, esto es, realiza la comunicaci´on punto a punto entre los dos hosts que interact´ uan. El IEEE ha desarrollado el est´andar 802.2 para especificar el protocolo de esta subcapa. 82

´ Este es compatible con todos los protocolos de nivel MAC de la serie 802, de forma que todas las redes locales 802 presentan una interfaz com´ un a la capa de red independientemente de cual sea el medio f´ısico y el protocolo MAC que se est´e utilizando. El protocolo LLC est´a basado en HDLC y suministra tres tipos de servicio: LLC Tipo 1. Datagramas sin acuse de recibo. Este es el m´as utilizado, es un servicio similar al ofrecido por PPP d´onde no existe control de flujo, pues no hay realimentaci´on del receptor al emisor. A diferencia de PPP aqu´ı no se realiza verificaci´on de errores pues ´esta ya ha sido efectuada por la subcapa MAC. LLC Tipo 2. Servicio confiable orientado a la conexi´on, similar al ofrecido por HDLC. Se realiza control de flujo y solicitud de retransmisi´on si detecta error en el checksum. LLC Tipo 3. Servicio intermedio de los dos anteriores. El emisor env´ıa datagramas y solicita acuse de recibo, pero ´estos son enviados tambi´en como datagramas, no hay un proceso expl´ıcito de establecimiento de la conexi´on como ocurre en el tipo 2. La mayor´ıa de los protocolos de red utilizados, como IP, requieren u ´nicamente el LLC de tipo 1, por lo que las funciones de la subcapa LLC son casi inexistentes. La principal funci´on que desempe˜ na la subcapa LLC es suministrar el soporte multiprotocolo, es decir multiplexar adecuadamente los frames recibidos de los diferentes protocolos posibles en el nivel de red antes de pasarlos a la subcapa MAC. Esto se hace mediante campos especiales del frame LLC. En el caso de redes Ethernet con frames en formato Ethernet la capa LLC es totalmente inexistente ya que esta informaci´on se suministra en el Ethertype. 1B

1B

DSAP SSAP

1-2 B

Variable

Control LLC

Datos a)

1B

1B

DSAP SSAP

1B

3B

2B

Variable

Control LLC

OUI

Tipo

Datos

b)

Figura 38: Formato del a) Frame IEEE 802.2 LLC b) Frame IEEE 802.2 LLC-SNAP.

El campo Control LLC especifica el tipo de servicio utilizado. En LLC tipo 2 se utilizan los mismos tipos de frame y comandos que en HDLC. En LLC tipo 1 el campo control siempre 83

vale 00000011 que significa frames no numerados. Los campos DSAP y SSAP tienen la finalidad de permitir identificar a que protocolo de red pertenece el frame LLC. Aunque se reserva un byte para especificar el protocolo los dos primeros bits del DSAP y el SSAP est´an reservados, ya que tienen significados de grupo/individual y local/global, igual como en las direcciones MAC del IEEE. Con s´olo 64 posibles valores el campo DSAP/SSAP se mostr´o r´apidamente insuficiente. La soluci´on al problema fue reservar un valor en el DSAP y el SSAP (11111111) para indicar la existencia de un campo adicional denominado SNAP, inmediatamente a continuaci´on del campo Control LLC y antes de los datos, que permite especificar cualquier protocolo. El campo SNAP se divide en dos partes: los primeros tres bytes forman lo que se denomina el OUI (Organizationally Unique Identifier) que identifica al fabricante que registra el protocolo ante el IEEE, mientras que los dos u ´ltimos identifican el protocolo dentro de ese fabricante. Un frame LLC es la manera normal de enviar los datos en cualquier LAN, excepto en Ethernet, donde existen dos posibilidades: Usar el campo longitud en el frame MAC y poner en el campo datos un frame LLC que contiene el tipo de protocolo utilizado a nivel de red. En este caso, normalmente se utilizar´a un frame LLC-SNAP, por lo que la longitud m´axima del paquete de nivel de red ser´a de 1492 bytes. Esta es la aproximaci´on empleada por Appletalk fase 2, NetBIOS y algunas implementaciones de IPX. Usar el campo tipo en el frame MAC y poner directamente en el campo datos el paquete de nivel de red. En este caso, la longitud m´axima del paquete a nivel de red podr´a ser de 1500 bytes. Este formato es empleado por TCP/IP, DECNET fase 4, LAT y algunas implementaciones de IPX.

2.14.

Dispositivos LAN

2.14.1.

Repetidores

Son dispositivos activos de solamente dos puertas, que permiten interconectar dos medios de comunicaci´on con el objeto de amplificar y reformar los pulsos constituyentes de la se˜ nal. Usualmente se utilizan para extender la longitud de los cables en una LAN o conectar medios de tipo diferente, generando una LAN u ´nica m´as extensa. Los repetidores interconectan las LAN al nivel del modelo de capas ISO/OSI m´as bajo, es decir, el nivel f´ısico. Esto significa, que los repetidores pueden s´olo conectar LAN id´enticas, tales como Ethernet/802.3 a 84

Ethernet/802.3 o Token Ring a Token Ring. Los repetidores Ethernet/802.3 dejan pasar todos los frames, para as´ı asegurar que todos los hosts respeten el m´etodo de detecci´on de colisi´on. M´as a´ un, debido a que un repetidores trabajan en el nivel f´ısico, ´estos no tienen idea que es o que significa un frame, ya que por inviolabilidad de los modelos de capas, un nivel no conoce ni interpreta los datos del nivel superior. El repetidor conocer´a entonces s´olo bits, es decir, los pulsos el´ectricos que aparecen en el medio. Se puede entender por segmento a la m´axima distancia que puede tener el medio f´ısico para conectar equipos en una red. Por ejemplo, si se usa coaxial delgado, un segmento de red podr´a tener una longitud m´axima de 185 mts, si se usa coaxial grueso, entonces el segmento m´aximo ser´a de 500 mts. Una LAN, t´ıpicamente, puede contener m´ ultiples segmentos de cable y m´ ultiples repetidores, y en IEEE 802.3 se permiten m´aximo 4. Los repetidores Ethernet/802.3 pueden tener sus puertas id´enticas o incluir combinaciones de los diferentes tipos permitidos por la norma IEEE 802.3. Con esto, permiten interconectar segmentos de medios f´ısicos diferentes. Cuando una colisi´on es detectada, el repetidor tambi´en coloca la se˜ nal de jamming para asegurar que todos los otros dispositivos se percaten que ha ocurrido una colisi´on. El detector de jam cuenta el n´ umero de colisiones consecutivas, y s´ı ´esta excede un valor predefinido, entonces el repetidor desactiva el segmento. S´ı se recibe un frame desde ese segmento de red, el repetidor lo reactiva autom´aticamente. De esta forma, segmentos con problemas son desconectados y segmentos v´alidos reconectados en forma din´amica. LAN 1

LAN 2

Dom. Colisión 1

Dom. Colisión 2 a) LAN

Dominio de Colisión b)

Figura 39: Extensi´on de una LAN usando un repetidor a) Dos LANes separadas y dos dominios de colisi´on b) LANes unidas por un repetidor y un u ´nico dominio de colisi´on.

Un dominio de colisiones se puede entender como toda la zona o distancia f´ısica en la que es probable que ocurra una colisi´on producto del funcionamiento de CSMA/CD. Si se tiene 85

un cable coaxial de 100 mts. del cual cuelgan nodos, entonces este segmento de 100 mts. es un dominio de colisiones. Ethernet permite extender una red LAN usando hasta un m´aximo de cuatro repetidores, que como se dijo anteriormente, repiten tambi´en la se˜ nal de jamming. Esto indica entonces que el conectar segmentos usando repetidores aumenta la probabilidad de colisiones, pues aumentar´a el round trip time de un frame y tambi´en aumentar´an la cantidad de nodos conectados. En otras palabras, el conectar redes usando repetidores significa que estamos aumentando en tama˜ no o extensi´on una LAN, pero se est´a manteniendo un u ´nico dominio de colisiones, lo que no es bueno para la eficiencia de la red (Figura 39). 2.14.2.

Hubs

Un hub es tambi´en un repetidor que tambi´en funciona en el nivel f´ısico del modelo ISO/OSI, y permite derivar desde un segmento u ´nico varios segmentos del mismo u otro tipo, y as´ı estructurar una LAN en mejor forma. En una red Ethernet/IEEE 802.3 los hub t´ıpicamente permiten crear derivaciones, por ejemplo, desde una red 10Base5 a m´ ultiples segmentos 10Base2, para implementar conexiones multipunto, o bien crean conexiones desde una red 10Base2 a m´ ultiples segmentos 10BaseT. Se puede decir entonces, que los hubs son realmente repetidores multipuerta. 2.14.3.

Bridges

Existen muchas circunstancias en las que no se quiere o no se puede tener una sola LAN. Por ejemplo: 1. Se dispone de un par de LANs diferentes (una Token Ring y una Ethernet) y desean conectarse. 2. Se necesita cubrir una distancia mayor que la que puede cubrirse con una LAN. 3. Se quiere conectar m´as nodos que los que se permiten en una LAN. 4. Se desea evitar que un problema en un nodo pueda colapsar toda la red, pues por ejemplo en Ethernet, una tarjeta en mal estado puede inutilizar toda la red. En estos casos, es posible tener m´ ultiples redes locales interconectadas mediante el uso de dispositivos llamados bridges o puentes. Los bridges son dispositivos de dos o m´as puertas, similares a los repetidores y hubs, pero que a diferencia de ellos se encargan de capturar los frames provenientes de una LAN y reenviarlos selectivamente a otra. Para esto, analizan la 86

direcci´on de origen y destino de cada frame recibido. Se desprende entonces que los bridges son dispositivos con un grado mayor de inteligencia que un repetidor o un hub, pues ´estos analizan los frames recibidos, por lo tanto, trabajan en un nivel distinto, y superior, al de los dispositivos de nivel f´ısico. Los bridges, debido al necesario procesamiento que realizan de la informaci´on operan en el nivel 2 del modelo ISO/OSI, pues ellos deben conocer las direcciones MAC de los nodos para poder realizar la repetici´on selectiva de frames, y es en este nivel donde aparece la unidad de informaci´on llamada frame. Los bridges, adem´as de ser repetidores selectivos de frames, proveen otra funci´on que es la de proveer buffers para los frames que ingresan y salen de sus puertas. Esto tiene una consecuencia muy importante, pues permiten eliminar colisiones, ya que el tener los buffers les permite almacenar algunos instantes los frames para su posterior reenv´ıo. Los repetidores y hubs al detectar una colisi´on la propagaban a los distintos segmentos que ´estos un´ıan, en cambio un bridge no la propagan sino que la evita. Debido a esto, cada puerta de un bridge es un dominio de colisiones distinto. De todo lo anterior es f´acil concluir los siguiente: 1. Para aumentar el tama˜ no o extensi´on de una LAN es bastante m´as eficiente utilizar bridges que repetidores o hubs debido a la separaci´on de los dominios de colisiones. 2. El usar un bridge para extender una LAN genera tantos dominios de colisiones como puertas tenga el equipo. 3. En teor´ıa no existe l´ımite para el n´ umero de bridges que se pueden utilizar para conectar o extender LANs. sin embargo, en la pr´actica la situaci´on es diferente, ya que los protocolos de comunicaci´on hacen que el desempe˜ no de la red global se vea degradado al usar s´olo bridges para comunicar LANs. De acuerdo a la funci´on que desempe˜ nan, los bridges se pueden clasificar en: puentes transparentes, puentes remotos, puentes traductores o puentes con encaminamiento desde el origen. Puentes Transparentes La idea tras estos bridges es que puedan utilizarse sin alterar el protocolo o la configuraci´on de los nodos. Normalmente estos equipos no necesitan ning´ un tipo de configuraci´on previa, actuando como dispositivos plug and play. Un puente transparente funciona de la siguiente forma: se supone que se tiene un bridge ´ de s´olo dos puertas que une LAN1 y LAN2. Este tendr´a dos interfases f´ısicas, cada una 87

conectada a una de las dos LANs. Al encender el bridge, ´este empieza reenviando todas los frames que recibe por LAN1 a LAN2, y viceversa. En todo momento, el bridge act´ ua en modo promiscuo, es decir, capturando todos los frames que se env´ıan por cada una de las redes a las que est´a conectado, independiente de cual sea la direcci´on de destino. Adem´as de reenviar los frames, el bridge extrae de cada uno de ellos la direcci´on de origen y la direcci´on de destino. La de origen la anota en una tabla (llamada SAT, Source Address Table) correspondiente a la LAN por la que ha llegado el frame, y la de destino la busca en la misma tabla. Suponiendo que el bridge recibe por la interfaz LAN1 un frame que lleva la direcci´on de origen A y la direcci´on de destino B. En primer lugar, el bridge actualizar´a su tabla de direcciones de LAN1 a˜ nadiendo A y despu´es buscar´a en su tabla si en la columna LAN1 aparece B. Si es as´ı sencillamente descartar´a el frame, ya que sabe que A y B est´an ambos en LAN1 y no hay ninguna necesidad de reenviar ese frame. Por el contrario, si B no aparece en la tabla de LAN1 el puente reenviar´a el frame a LAN2. Es posible que B est´e en LAN1 y el bridge no lo sepa, porque B no haya enviado a´ un ning´ un frame, pero ante la duda, el bridge reenv´ıa el frame por la otra interfaz. Esta estrategia de tirar por elevaci´on enviando la informaci´on en caso de duda se denomina inundaci´on (flooding). En resumen, el bridge construye una tabla en la que mantiene una relaci´on entre las direcciones MAC y la puerta a la que est´a conectada cada MAC, ya que as´ı sabe hacia cual de sus puertas o interfases reenviar la informaci´on. Este mecanismo de aprendizaje tiene algunas consecuencias que vale la pena destacar: un nodo que no emita ning´ un frame, no puede ser localizado, por lo que un bridge enviar´a por todas sus interfases los frames dirigidos a dicho nodo. Los frames enviados a direcciones multicast o broadcast siempre son retransmitidos por todas las interfases, ya que en principio puede haber destinatarios en cualquier parte. Se deduce entonces, que los bridges no almacenan direcciones multicast en sus tablas. Finalmente, cuando un nodo transmite un frame con direcci´on destino FF:FF:FF:FF:FF:FF, el frame es retransmitido por todas las puertas del bridge, pues debido a que la direcci´on destino es la direcci´on de broadcast, todos los nodos deben recibir el frame. El u ´ltimo caso de forma de operaci´on de un bridge est´a relacionado con el concepto de dominio de broadcast. Un dominio de broadcast se puede entender como toda la zona o distancia l´ ogica en la que un frame dirigido a FF:FF:FF:FF:FF es recibido por los nodos conectados a una LAN. Por ejemplo, si se tienen tres redes LAN conectadas a trav´es de dos bridge de dos puertas cada uno, entonces se tiene un u ´nico dominio de colisiones pues debido a la forma de operar, todo bridge que reciba un frame dirigido a la direcci´on de broadcast 88

Cloud

Dom. Colisión 1

Dom. Colisión 2 Dominio de Broadcast

Dom. Colisión 3

Figura 40: Extensi´on de una LAN usando bridges: una LAN, tres dominios de colisi´on y un u ´nico dominio de broadcast.

debe reenviar el frame por todas sus puertas. Notar tambi´en que en esta misma situaci´on se tiene un u ´nico dominio de broadcast, pero tres dominios de colisiones distintos (Figura 40). Como una forma de adaptarse a cambios de topolog´ıa en la red, las entradas en las tablas de direcciones son eliminadas cuando han pasado varios minutos sin que la direcci´on correspondiente haya enviado datos. Existen bridges multipuerta, es decir, con m´ ultiples interfases, que permiten interconectar varias LANs en un mismo equipo. El algoritmo en estos casos es similar, salvo que se mantiene una tabla de direcciones para cada interfaz. Las tablas se van llenando con las direcciones escuchadas en cada interfaz. Cuando se recibe un frame en cualquiera de las interfases se busca la direcci´on de destino en la columna de dicha interfaz, y si el destinatario se encuentra all´ı, el frame simplemente se descarta, si no se busca en las columnas correspondientes a las dem´as interfases. Si se encuentra en alguna columna se env´ıa a la interfaz correspondiente. Por u ´ltimo, si no se encuentra en ninguna de las tablas se env´ıa a todas las interfases excepto aquella por la que lleg´o (flooding). Los bridges han de mantener una tabla de direcciones para cada una de sus puertas; la cantidad de memoria destinada a dichas tablas es limitada, y en redes grandes puede llegar a agotarse. Los fabricantes suelen especificar el n´ umero m´aximo de direcciones MAC que sus puentes son capaces de soportar. El protocolo Spanning Tree . En algunas situaciones, resulta interesante unir dos LANs con m´as de un bridge. Si se tienen LAN1 y LAN2, unidas por los puentes B1 y B2 (Figura 41), y un nodo en LAN1 emite un frame que lleva una direcci´on de destino F a´ un no registrada. Al no aparecer en sus tablas B1 reenv´ıa el frame a LAN2, y lo mismo hace B2. A continuaci´on, B1 detecta en LAN2 el frame generado por B2 y, al no encontrar en sus tablas la direcci´on de destino, ya que a´ un no se conoce la ubicaci´on de F, lo reenv´ıa a LAN1. An´alogamente, B2 detecta en LAN2 el frame de B1 y al no estar F en su tabla de direcciones, lo reenv´ıa a 89

LAN1

B1

Loop

B2

LAN2

Figura 41: Loop formado por la conexi´on de LANs usando bridges

LAN1. LAN1 recibe dos copias de un frame que ya ten´ıa, y se repite el proceso: B1 recoge el frame de B2 y lo retransmite. B2 hace lo mismo con el de B1, y as´ı sucesivamente. El ciclo no tiene fin, por lo que un s´olo frame es suficiente para saturar ambas redes. Para evitar este problema existe un mecanismo que permite a los bridges comunicarse entre s´ı, pas´andose informaci´on sobre la topolog´ıa de las conexiones existentes. Una vez conocida la topolog´ıa los bridges desactivar´an las conexiones redundantes para garantizar que haya un u ´nico camino uniendo todas las redes, de forma que se evite la creaci´on de loops. Las conexiones que l´ogicamente se pongan fuera de servicio quedar´an listas para entrar en funcionamiento si las conexiones activas fallan por alg´ un motivo. El algoritmo se repite cada cierto tiempo, por lo que si alguno de los enlaces queda fuera de funcionamiento por alg´ un motivo en la siguiente ronda se habilitar´a alg´ un camino alternativo que lo sustituya. El protocolo que permite esto se conoce como Spanning Tree o como Spanning Tree Learning Bridge Protocol, y forma parte de la especificaci´on IEEE 802.1d. Puentes Remotos En ocasiones existe la necesidad de conectar entre s´ı dos LANs remotas como si fueran la misma LAN (una conexi´on WAN para formar una LAN extendida, como es el caso de las ´ conexiones de la Universidad de Concepci´on entre los campus de Concepci´on, Los Angeles y Chill´an). Para esto se usa un tipo de bridge denominados puentes remoto. El mecanismo b´asico de funcionamiento es el mismo que para los puentes locales, salvo que el puente est´a constituido por dos “medios puentes” interconectados por una l´ınea dedicada cuya velocidad t´ıpicamente suele estar entre 64 Kbps y 2048 Mbps. Tambi´en se pueden unir los puentes remotos por redes X.25, Frame Relay o incluso radioenlaces. El protocolo spanning tree tambi´en se utiliza en bridges remotos. Para representar topol´ogicamente un bridge remoto el enlace punto a punto se debe considerar como una LAN con un 90

bridge en cada extremo. Dado que generalmente los bridges remotos se conectan mediante l´ıneas de menor velocidad que las redes a las que enlazan, es frecuente que dicha conexi´on sea el factor limitante del desempe˜ no de la red. Esto es especialmente cr´ıtico cuando se utilizan l´ıneas de baja velocidad y m´as a´ un cuando se trata de LANs grandes en las que el tr´afico broadcast/multicast es importante. Puentes Traductores Un puente traductor es aquel que interconecta dos redes que utilizan diferente protocolo MAC, por ejemplo Ethernet y Token Ring. La utilizaci´on de puentes traductores tiene diversos problemas entre los que se destacan los siguientes: Reformateo del frame. La estructura del frame en ambas redes es diferente. Adem´as de acomodar los datos a la nueva estructura es necesario recalcular el CRC. Campos inexistentes. Cuando se pasa de Token Ring a Ethernet los campos prioridad y reserva se pierden, y en el sentido inverso, al pasar de Ethernet a Token Ring es preciso asignar un valor arbitrario a los campos prioridad y reserva sin disponer de ninguna informaci´on al respecto. Acuse de recibo. Los bits A y C del campo Frame Status en Token Ring, que permiten indicar un acuse de recibo al nodo emisor, plantean un problema cuando el frame atraviesa el bridge. Si el bridge no acusa recibo es muy probable que el emisor reintente varias veces, hasta abandonar. Por el contrario, si el puente acusa recibo est´a mintiendo, ya que podr´ıa presentarse alg´ un problema m´as tarde en el env´ıo del frame a su destino y el nodo que env´ıa el frame creer´a que todo es correcto. Formato de las direcciones MAC. Aunque tanto Ethernet como Token Ring soportan las direcciones IEEE de 48 bits en Ethernet las direcciones MAC se transmiten enviando primero el bit menos significativo de cada byte, mientras que en Token Ring se transmite primero el bit m´as significativo. Los puentes entre ambas redes han de tener esto en cuenta para invertir el orden de los bits de cada byte cuando se transmite un frame. El tema se complica cuando aparecen direcciones MAC en la parte de datos del frame, como en los paquetes ARP y RARP utilizados en IP para la resoluci´on de direcciones. Diferente tama˜ no de frame m´ aximo. El campo datos en el frame Ethernet tiene un tama˜ no m´aximo de 1500 bytes. En cambio en Token Ring est´a limitado u ´nicamente 91

por el token-holding time. Con el valor por defecto de 10 ms esto supone 5000 bytes a 4 Mbps y 20000 bytes a 16 Mbps. De todos estos problemas el u ´ltimo es el m´as grave, y existen tres posibles soluciones, de las cuales normalmente se adopta la tercera. 1. Cada nodo de la red Token Ring limita a 1500 bytes el tama˜ no m´aximo de frame. Esto reduce el grado de transparencia de la red. 2. Los bridges segmentan los frames Token Ring superiores a 1500 bytes en frames menores, cada una con la misma direcci´on origen y direcci´on destino que el frame original. Esta funci´on no forma parte del est´andar 802.1D y no est´a soportada normalmente por los bridges, adem´as aumenta el tiempo de proceso. 3. Las redes se unen mediante un router, en vez de un bridge. El router act´ ua al nivel de red y dispone de los recursos necesarios para extraer el paquete del frame, fragmentarlo si es preciso, y generar uno o varios frames en la otra red. El problema en este caso es que el router no puede ser transparente al tipo de protocolo utilizado en el nivel de red, que era una de las grandes ventajas de los puentes. Puentes con Encaminamiento Desde el Origen Aunque podr´ıan utilizarse en cualquier LAN, los bridges con encaminamiento desde el origen se utilizan u ´nicamente en Token Ring, y su estandarizaci´on est´a recogida en el IEEE 802.5. La idea consiste en que el host que genera el frame disponga de suficiente informaci´on sobre la topolog´ıa de la red como para que pueda indicar la ruta que debe seguir el frame en todo su recorrido. Para poder indicar la ruta, el emisor incluye la informaci´on pertinente en un campo adicional del frame, ubicado detr´as del campo direcci´on origen. Se utiliza para ello una versi´on modificada del frame normal Token Ring. La presencia de informaci´on de routing se indica poniendo a 1 el primer bit de la direcci´on origen. La informaci´on de routing est´a formada por una secuencia de n´ umeros de: bridge, LAN, bridge, LAN, etc. hasta llegar a la LAN de destino. Para esto, en la red Token Ring las LANs se numeran con direcciones de 12 bits u ´nicas en toda la red, y los bridges con direcciones de 4 bits u ´nicas en el contexto de las LANs que interconectan. Un bridge con encaminamiento desde el origen descarta autom´aticamente todos los frames que no tienen en 1 el primer bit de la direcci´on origen, ya que se supone que estas no deben ser 92

encaminadas. Para el resto, el bridge analiza la informaci´on de routing y busca del n´ umero de la LAN por la que le ha llegado. Si este n´ umero de LAN es seguido por su propio n´ umero de bridge, entonces reenv´ıa el frame a la LAN que le sigue en la secuencia. Si no es as´ı, entiende que el frame no va dirigido a ´el y lo descarta. Para poder incluir la informaci´on de routing los hosts deben obtener informaci´on sobre la topolog´ıa de la red. Para ello, cuando un nodo desea saber la ruta por la que puede llegar a otro cuyo destino le es desconocido env´ıa una frame especial, llamado discovery frame, en todas direcciones, de forma que sea retransmitido por todos los bridges en todas las LANs. Eventualmente el frame llega a su destino por uno o m´as de los posibles caminos, y el nodo destino responde con un frame de acuse de recibo que viaja en orden inverso, pero esta vez cada puente por el que pasa anota en el frame de respuesta su propio n´ umero y el n´ umero de la LAN por el que lo emite. Al final del proceso la estaci´on origen recibe uno o varios frames que le indican todas las rutas posibles hacia el destino especificado y elige la que considera ´optima y la incluye en su tabla de rutas para poder utilizarla en posteriores env´ıos a dicha estaci´on.

2.15.

LAN Conmutadas

En la actualidad los bridges presentan un elevado n´ umero de interfases, habiendo modelos que pueden llegar a tener m´as de 500. Estos equipos suelen ir equipados con chips VLSI dise˜ nados espec´ıficamente para este tipo de tareas lo que aumenta su desempe˜ no. A estos bridges multipuerta de alta velocidad se les llama switches LAN, ya que gracias al redireccionamiento inteligente que realizan mediante sus tablas de direcciones act´ uan conmutando frames entre sus m´ ultiples puertas. Aquellas LANs basadas en switches se las suele llamar LAN conmutadas. En los switches Ethernet, al igual que en los bridges, se dice que cada puerto constituye un dominio de colisiones independiente, ya que las colisiones que se producen en un puerto no afectan a los dem´as. Los switches Token Ring pueden funcionar seg´ un el principio de bridge con encaminamiento desde el origen o como bridge transparente. Con switches LAN de elevado n´ umero de puertas es posible incrementar de forma notable la capacidad de una red local con una modificaci´on m´ınima de la misma. Por ejemplo, si en una red se sustituye un hub Ethernet de 24 puertas por un switch LAN de 24 puertas, el rendimiento m´aximo te´orico se ha multiplicado por 24 sin haber tenido que modificar el cableado o las tarjetas de red de los hosts. Notar que el desempe˜ no de la red es el que aumenta,

93

no la velocidad de operaci´on, la cual sigue siendo exactamente la misma. En el caso de redes Ethernet el uso de switches tiene un efecto adicional en la mejora del rendimiento. Se debe recordar que en redes CSMA/CD la eficiencia disminuye a medida que aumenta el n´ umero de nodos, por lo que si se divide una red en varias mediante un switch se consigue un mejor rendimiento en cada unp de los dominios de colisiones generados, los cuales soportar´an un n´ umero reducido de equipos. La Figura 42 muestra un resumen de los equipos de comunicaci´on utilizados en una red LAN. En el nivel f´ısico se encuentran los repetidores y hubs, cuya funci´on es ampliar la extensi´on de una red manteniendo un u ´nico dominio de colisiones y un u ´nico u ´nico dominio de broadcast. En el nivel de enlace se observan los bridges y switches los ue adem´as de permitir extender las redes a´ıslan los dominios de colisi´on, pero mantienen un u ´nico dominio de broadcast. Capa de Enlace de Datos

Subcapa LLC Subcapa MAC

Capa Física

Modelo OSI

Figura 42: Equipos de Comunicaci´on LAN. Repetidores y Hubs en el Nivel F´ısico y Bridges y Switches en el Nivel de Enlace.

Un problema que se presenta con los switches LAN es que se pueden producir situaciones de congesti´on, para las que no disponen de muchos mecanismos de control, pues ´estos, al igual que los bridges, funcionan u ´nicamente a nivel de enlace. Por ejemplo, si en un switch de puertas a 10 Mbps, diferentes puertos quieren enviar tr´afico a la vez a un mismo puerto a 10 Mbps cada uno y ´esta situaci´on se mantiene durante bastante tiempo el switch puede agotar el espacio en buffers disponible, perdi´endose frames a partir de ese momento. En el caso de Ethernet, este problema se resuelve mediante el control de flujo. Al igual que los bridges, los switches LAN han de mantener en memoria las tablas de direcciones MAC en cada una de sus puertas. Las especificaciones de un switch LAN indican normalmente el n´ umero m´aximo de direcciones que puede soportar. Si el n´ umero de equipos activos en la red es superior a este n´ umero m´aximo, el rendimiento de la red se ve afectado ya 94

que las entradas en la tabla de direcciones expiran con demasiada rapidez, provocando tr´afico adicional en la red debido al mecanismo de flooding. 2.15.1.

Store and Forward vs Cut-Through

Dado que los switches LAN son esencialmente bridges con muchas puertas, su funcionamiento normal requiere que antes de retransmitir un frame lo reciban en su totalidad para que puedan comprobar el CRC y descartarlo en caso de que ´este sea err´oneo. Esto obliga a que los switches funcionen como dispositivos de almacenamiento y reenv´ıo (Store and Forward). En el caso de frames grandes el requerimiento de comprobaci´on del CRC introduce un retardo notable en la propagaci´on del frame, a menudo superior al que introduce el propio proceso de conmutaci´on. Adem´as, si el frame ha de atravesar varios switches el almacenamiento y reenv´ıo se ha de realizar en cada uno de ellos. Si no se hiciera la comprobaci´on del CRC la velocidad de conmutaci´on podr´ıa aumentarse notablemente y el retardo reducirse, ya que el switch podr´ıa empezar a enviar los bits tan pronto hubiera recibido la direcci´on MAC a la que va dirigido el frame. A este tipo de funcionamiento alternativo se le conoce como funcionamiento en modo Cut-Through. El problema del Cut-Through es que se pueden estar produciendo errores de CRC que pasen inadvertidos, y en este caso los frames err´oneos ser´an descartados por el host de destino, por lo que no hay riesgo de que se interpreten como correctos datos err´oneos, pero aun as´ı la situaci´on es perjudicial para la red puesto que se esta ocupando ancho de banda con tr´afico in´ util. Para evitar este problema cuando los switches funcionan en modo Cut-Through siguen comprobando el CRC, y cuando se produce un error no pueden descartar el frame, puesto que ya ha sido transmitido, pero s´ı pueden poner al nodo emisor bajo sospecha y a partir de ese momento pasar a funcionar en modo store and forward de forma selectiva, u ´nicamente para los frames que tengan como direcci´on de origen la del nodo sospechoso. Si se comprueba m´as tarde que el error detectado fue algo espor´adico se volver´a al modo Cut-Through, de lo contrario se mantendr´a el estado de vigilia. Full D´ uplex Ethernet Debido al origen de Ethernet, ´esta siempre ha sido una tecnolog´ıa half d´ uplex. Ethernet Full D´ uplex permite la transmisi´on y recepci´on de un frame al mismo tiempo, y para ello requiere el uso de dos pares de cables y una conexi´on conmutada entre los nodos origen y destino, que es provista por los switches LAN. Esta conexi´on es considerada punto a punto y libre de colisiones, por lo tanto, para que Ethernet Full D´ uplex funcione deben darse las sigu95

ientes condiciones: el medio f´ısico debe permitir transmisi´on full-d´ uplex como en 10BaseTX, 100BaseTX, etc. (quedan excluidos 10BASE5, 10BASE2 y 100BASET4); s´olo deben haber dos estaciones conectadas entre s´ı (por ejemplo, switch-switch, switch-host o host-host) y las interfases de red y de ambos nodos soporten el funcionamiento en modo Full D´ uplex. Es as´ı como el switch saca partido de la configuraci´on, ya que genera conexiones entre el par TX y el RX de los nodos emisor y receptor, respectivamente. De esta forma se crea un dominio libre de colisiones para los nodos, debido a que la transmisi´on y recepci´on est´an separadas en circuitos independientes. En Gigabit Ethernet Full D´ uplex se suprime la extensi´on de portadora, ya que es innecesarias, debido a la que no existe medio compartido y no se requiere funcionamiento del tipo CSMA/CD. Por lo tanto, las ventajas en Gigabit Ethernet Full D´ uplex son a´ un mayores que las obtenidas en Ethernet o Fast Ethernet. La introducci´on del funcionamiento Full D´ uplex introduce una nueva funcionalidad, el control de flujo, que se implementa mediante el comando PAUSE. El receptor puede en cualquier momento enviar al emisor un comando PAUSE indic´andole por cuanto tiempo debe dejar de enviarle datos. Durante ese tiempo, el receptor puede enviar nuevos comandos PAUSE prolongando, reduciendo o suprimiendo la pausa inicialmente anunciada. Con esto se pretende evitar la saturaci´on de los buffers del receptor y, por lo tanto, el descarte de frames, lo que causar´ıa una p´erdida considerable de rendimiento. 2.15.2.

LANs virtuales o VLANs

Una de las grandes virtudes de bridges y switches es su sencillez de manejo. Debido a su funcionamiento transparente es posible realizar una compleja red, incluso con enlaces WAN si se utilizan bridges remotos, sin tener que configurar ning´ un router. A fines de los ochenta se puso de moda la idea de desarrollar grandes redes, incluso a nivel de redes nacionales, basadas u ´nicamente en el uso de puentes transparentes. Sin embargo pronto se vio que esta estrategia ten´ıa dos inconvenientes serios: Los bridges propagan el tr´afico broadcast y multicast. Generalmente los protocolos orientados a redes locales hacen un uso exhaustivo de este tipo de frames, especialmente los broadcast, para anunciar todo tipo de servicios. Incluso el protocolo de red IP, emplea broadcasting para la resoluci´on de direcciones. La proliferaci´on de tr´afico broadcast en una red es especialmente grave m´as que por el ancho de banda desperdiciado por el consumo de ciclos de CPU que se produce en todos los nodos de la red. Este no es el 96

caso con los frames multicast, ya que cuando un frame multicast no incumbe a una estaci´on es descartado por la interfaz. La transparencia de los bridges hace dif´ıcil establecer mecanismos de control, protecci´on y filtrado de tr´afico, por lo que las redes muy grandes basadas en bridges se hacen inmanejables. Adem´as, en los casos en que se requieren controles o mecanismos de administraci´on se han de utilizar direcciones MAC que no tienen ning´ un prefijo com´ un que permita referirse o identificar una parte de la red, ya que la asignaci´on no ha seguido ning´ un criterio geogr´afico ni corresponde con la topolog´ıa de la red. Como consecuencia de esto la creaci´on de grandes redes locales est´a desaconsejada y es pr´actica habitual en estos casos separar mediante routers las diversas partes de la red. Este es el caso en un campus o gran edificio. Los routers, son equipos de comunicaciones que act´ uan a nivel de red, aislando los frames broadcast y multicast (es decir, no los retransmite por sus otras interfases como lo hace un bridge o switch) y facilitando la administraci´on al agregar las direcciones de nivel de red y un ordenamiento l´ogico de m´as alto nivel. Se puede observar entonces que un router, por el hecho de aislar los broadcast, genera tantos dominios de broadcast como interfases tenga.

Piso Investigación

Piso Docencia

Piso Estudiantes

Piso Administración

Usuario Investigación

Usuario Docencia Usuario Estudiantes

Usuario Administración

Figura 43: Organizaci´on por piso para los cuatro grupos de trabajo.

Dividir una red local con criterios geogr´aficos resulta relativamente sencillo, ya que normalmente la topolog´ıa del cableado permite realizar esa divisi´on de manera directa. Por ejemplo, 97

si se quiere dividir en varias una red local que abarca el campus de una universidad, se puede crear una LAN por edificio con switches en cada edificio e interconectar cada edificio a una interfaz diferente de un router que interconecte todo el campus, para as´ı aislar los dominios de broadcast y mantener comunicadas todas las LANs. Sin embargo, a menudo se requiere realizar una divisi´on l´ogica de acuerdo a criterios funcionales, que no siempre coinciden con la ubicaci´on f´ısica. Por ejemplo, en el caso de una universidad se podr´ıa pensar por razones de eficiencia y seguridad en crear una red para investigaci´on, otra para docencia, otra para estudiantes y una u ´ltima para tareas administrativas. Normalmente habr´a varios edificios en los que habr´a que dotar una serie de puestos de cada una de las cuatro redes mencionadas, en cuyo caso habr´ıa que instalar en los correspondientes armarios de cableado switches independientes e interconectarlos entre s´ı por separado. Esto provoca una red compleja y muy cara, ya que en muchos casos habr´a equipos subutilizados.

Piso 4

Piso 3

Piso 2

Piso 1

Usuario Investigación

Usuario Docencia Usuario Estudiantes

Usuario Administración

Figura 44: Organizaci´on usando m´ ultiples switches para los cuatro grupos de trabajo.

El problema que se presenta es simple, se desea tener redes aisladas, a nivel de enlace, para los cuatro grupos de trabajo mencionados. La soluci´on es sencilla si se dispone de espacios f´ısicos contiguos para todos los miembros de un mismo grupo, como por ejemplo un edificio o piso para administraci´on, otro para alumnos, etc. (Figura 43). Pero, generalmente esto no sucede y existe una mezcla de usuarios en un mismo edificio y/o piso. La soluci´on pasar´a entonces por la mencionada opci´on de tener por cada piso y/o edificio un switch para cada grupo de trabajo (Figura 44), con el fin de nunca mezclar los tr´aficos, y lograr la conectividad 98

entre las cuatro LANes usando un router de cuatro interfases que permita comunicarlas a un nivel superior (nivel de red). La soluci´on actual a este problema es la creaci´on de redes locales virtuales, o VLANs. Las VLANs son una forma de realizar una partici´on l´ogica de un switch en otros m´as peque˜ nos, de forma que aunque se trata de un solo equipo, se dividen los puertos en grupos que son completamente independientes entre s´ı. Un switch que tiene la capacidad de generar VLANs se puede considerar como un switch que, por software, se convertir´a en tantos switches como VLANs se creen, es decir, si se crean las cuatro VLANs necesarias para el ejemplo en un switch, esto se puede ver como si se hubieran comprado cuatro switches y cada uno de ellos genera una LAN para cada grupo de trabajo, y los tr´aficos, a nivel de enlace, nunca se mezclar´an entre las VLANs, pues la u ´nica forma de hacerlo es utilizando un router que comunique, a nivel de red, las cuatro VLANs generada. Un switch con capacidades de VLANs es entonces un generador de diversos dominios de broadcast. La funcionalidad o soporte de VLANs est´a disponible hoy en d´ıa en la mayor´ıa de los switches del mercado. Suponiendo el caso anterior, que se ha decidido dividir la red de campus en cuatro VLANs: I (de investigaci´on), D (de docencia), E (de estudiantes) y A (de administraci´on). Si se tiene un switch de 24 puertas en un closet de cableado y se plantea la necesidad de suministrar servicio a 8 equipos de la VLAN I, 4 de la D, 4 de la E y 4 de la A. Se podr´ıa asignar, por ejemplo, los puertos 1 a 8 a la VLAN I, 9 a 12 a la VLAN D, 13 a 16 a la VLAN E y 17 a 20 a la VLAN A, dejando los puertos 21 a 24 libres para futuras ampliaciones o para conectar las interfases de un router, etc. A partir de ese momento, el switch se comportar´a como cuatro switches virtuales de 4 puertos cada uno, los correspondientes a las tres VLANs y un cuatro correspondiente a los puertos no asignados. De esta forma, se puede asignar puertos a una u otra VLAN de forma flexible en funci´on de las necesidades (Figura 45). Queda por resolver a´ un la conexi´on de las cuatro VLANs con el resto de la red. Una posibilidad ser´ıa asignar los puertos 21 a 24 a cada una de las cuatro VLANs y conectarlos a cuatro puertas del switch principal del edificio creando tambi´en cuatro VLANs. Siguiendo este sistema, se llegar´ıa al router del campus donde un switch con puertos en las cuatro VLANs se conectar´ıa a cuatro interfases f´ısicas diferentes del router. Aunque f´ısicamente las cuatro VLANs comparten los switches, sigue habiendo cuatro redes separadas en el cableado, ya que nunca viajan por un mismo cable frames de VLANs diferentes. Cabe tambi´en pensar en un nivel adicional de optimizaci´on en el que se compartiera un mismo cable para diferentes VLANs. Esto permitir´ıa un ahorro considerable en el n´ umero de puertos consumidos en los enlaces troncales, especialmente cuando se manejan muchas 99

Piso 4

Piso 3

Piso 2

Piso 1

VLAN Investigación

VLAN Docencia VLAN Estudiantes

VLAN Administración

Figura 45: Organizaci´on usando VLANs y enlaces Trunk para los grupos de trabajo

VLANs. Por ejemplo, se podr´ıa emplear s´olo un puerto, por ejemplo el 21, para conectar las cuatro VLANs, liberando as´ı los puertos 22 a 24 para otros usos. Esta situaci´on se denomina configurar un enlace trunk o troncal. Debiera ser l´ogico entonces que los enlaces Trunk suelan ser de mayor capacidad que los puertos normales del switch ya que soportan un tr´afico m´as elevado. Por ejemplo, en un switch de puertos a 10 Mbps el enlace trunk t´ıpicamente ser´a de 100 Mbps y en uno con puertos de 100 Mbps ser´a de Gigabit Ethernet. Los enlaces Trunk suponen un cambio importante en el funcionamiento de los switches, ya que al mezclar frames de diferentes VLANs por el mismo cable es preciso marcarlas o etiquetarlas de alguna manera a fin de poder entregarlas a la VLAN adecuada en el otro extremo. El marcado se hace a˜ nadiendo un campo nuevo en el header del frame MAC, lo que hace que el tama˜ no del frame Ethernet supere ligeramente la longitud m´axima de 1500 bytes en algunos casos, ya que un switch puede recibir un frame de 1500 bytes y si lo ha de enviar por un enlace trunk tendr´a que incorporarle la etiqueta correspondiente, pues en ning´ un caso est´a permitido fragmentar el frame original. Hoy en d´ıa existe un formato est´andar para colocar las etiquetas de VLAN que es el conocido como IEEE 802.1q que es el que utilizan pr´acticamente la totalidad de los equipos actuales. De esta forma es posible dise˜ nar complejas redes con VLANs utilizando equipos de diferentes fabricantes. Una propiedad interesante de las VLANs es la posibilidad de configurar interfases virtuales en los hosts. Suponiendo que en el caso analizado con las cuatro VLANs, I, D, E y A, se tiene 100

un servidor que se desea est´e accesible de forma directa en las cuatro VLANs, de forma que cualquier host de cualquiera de las VLANs pueda acceder a ´el sin necesidad de pasar por un router. Una posible soluci´on ser´ıa conectar al servidor mediante cuatro interfases de red y conectar cada una de ellas a un puerto del switch asignado a cada una de las VLANs. Cada interfaz recibir´ıa una direcci´on de red correspondiente a la VLAN en la que se encuentra. Sin embargo, esta soluci´on se hace inmanejable si aumenta el n´ umero de VLANs. Otra posibilidad, m´as interesante, ser´ıa configurar una interfaz de red del servidor como tres interfaces virtuales y conectarla a un puerto trunk del switch. Para esto se necesita disponer de drivers con soporte de IEEE 802.1q para la interfaz de red y el sistema operativo que se est´e utilizando. Finalmente se puede comentar que la pertenencia o membres´ıa de un nodo a una cierta VLAN no s´olo es configurable por puerto, en general se tienen las siguientes posibilidades: 1. VLAN de Nivel 1. Corresponde a las VLAN ya mencionadas, donde la pertenencia est´a asociada al puerto al que est´e conectado un equipo. Son llamadas tambi´en VLAN por puerto, y tienen una tabla en la que asocian el n´ umero de puerto con el VLAN ID. Su principal desventaja es que no permite movilidad, ya que si un usuario se cambia, se debe reasignar el puerto para que ´este siga en la misma VLAN. 2. VLAN de Nivel 2. Son VLANs en las que la membres´ıa se basa en la direcci´on MAC que tiene el equipo a conectar, y por lo tanto, el frame emitido. En este caso, el equipo mantiene una tabla en la que existe una relaci´on entre MAC y VLAN ID, lo que permite movilidad para los usuarios. 3. VLAN de Nivel 2. Otra forma de clasificar los usuarios de las VLAN es usando el campo Protocol Type del frame, y si por ejemplo, el protocolo de red usado es IP el frame se asocia a la VLAN 1, si es IPX, se asocia a la VLAN 2, etc. Por lo tanto, el equipo mantiene una tabla en la que existe una relaci´on entre el protocolo de nivel de red y el VLAN ID. 4. VLAN de Nivel 3. En este caso, las VLAN se asocian a la direcci´on de red o de subred que tenga el equipo. Por ejemplo, todos los equipos cuya direcci´on de red sea 152.74.20.0 se asocian a la VLAN 1, los que tengan la direcci´on de red 152.74.21.0 se asocian a la VLAN 2, etc. En este caso, la tabla que se mantiene es de direcci´on de red y VLAN ID. El hecho de observar la direcci´on de red dentro del frame no implica que el equipo haga routing, sino que es esa informaci´on la que sirve para la clasificaci´on de los equipos. La ventaja de hacer esto es que si un usuario se mueve, no necesita reconfigurar 101

los par´ametros de red del equipo, y la desventaja es el mayor tiempo de procesamiento de la informaci´on antes de reenviar el frame. 5. VLAN de Nivel Superior. Tambi´en es posible definir VLAN bas´andose, por ejemplo, en el tipo de aplicaci´on o de servicio que est´a encapsulado en el frame. As´ı, por ejemplo, podr´ıa tenerse una VLAN para todos los frames que tengan datos de FTP, otra para los que tengan datos HTTP, etc. La Tabla 6 muestra un resumen de la organizaci´on e interconexi´on de LANs usando los distintos equipos de nivel f´ısico y de enlace vistos hasta el momento, y su relaci´on con los dominios de colisi´on y de broadcast. Tabla 6: Relaci´on entre los equipos de comunicaci´on LAN y los dominios de colisi´on y broadcast Equipo

Nivel de Trabajo

No Puertos

Dominios Colisi´on

Dominios Broadcast

Repetidor

F´ısico

n

1

1

Hub

F´ısico

n

1

1

Bridge

Enlace

n

n

1

Switch

Enlace

n

n

1

Enlace y sup.

n

n

m

Switch VLAN

2.16.

LAN Emulation: ATM y su Interconexi´ on LAN

La clave para el ´exito de ATM reside en la capacidad que tenga de operar con las redes de datos que actualmente se encuentran en operaci´on. Para ello, la interconexi´on debe ser usando los mismos protocolos de nivel de red que est´an en uso, como IP e IPX. El protocolo LAN Emulation o LANE lo que hace es definir una interfaz de servicios para los protocolos del nivel superior, que es id´entica a la existente en las LANs y los datos enviados a trav´es de la red ATM son encapsulados en el formato apropiado de paquetes LAN MAC. Esto no significa que se intente emular el m´etodo de control de acceso al medio (CSMA/CD para Ethernet y token passing para Token Ring) en la LAN emulada. En otras palabras, los protocolos LANE hacen que una red ATM se vea y comporte como una LAN Token Ring o Ethernet, pero operando a mucho mayor velocidad. La raz´on de todo esto es que as´ı no se requieren modificaciones sobre los protocolos de nivel 3 existentes. Es as´ı como el funcionamiento b´asico de LANE es la resoluci´on de direcciones MAC en direcciones ATM. 102

Est´a considerado que LANE ser´a desarrollado sobre tipos de equipos ATM: 1. ATM Network Interface Cards (NIC): que implementar´a LANE y ser´an la interfaz hacia la red ATM, pero ofreciendo una interfaz de servicio corriente a los drivers de los protocolos de nivel superior. La comunicaci´on ser´a igual que si estuvieran en una LAN. Sin embargo, ser´an capaces de usar un ancho de banda mucho mayor. En palabras simples, esto puede tomarse como un nodo final o computador con una tarjeta de red ATM ejecutando los protocolos LANE. 2. Equipos de Red y Switches LAN: corresponde a switches LAN y routers asociados a equipos ATM. Los switches LAN ser´an usados para proporcionar servicios de LAN virtuales. Los equipos de red como los routers tambi´en permitir´an la implementaci´on de LANs virtuales a nivel de red. La Figura 46 muestra la arquitectura del protocolo LANE. Protocolos de nivel superior

Protocolos de nivel superior

IP, IPX, etc.

IP, IPX, etc.

NDIS/ODI

802.1D

LANE Señalización UNI

Señalización UNI

AAL 5

Host ATM con NIC LANE

MAC

MAC

Físico

Físico

AAL 5

ATM Físico

NDIS/ODI

LANE

ATM Físico

ATM Físico

Físico

Switch ATM

Switch LAN de Nivel 2

Host LAN

Figura 46: Arquitectura del Protocolo LANE.

Componentes y tipos de Conexi´ on LANE Una LAN emulada (ELAN), ya sea Ethernet o Token Ring, consiste de las siguientes entidades (ver Figura 47): Cliente LANE o LEC. Es la entidad que en un sistema final, ejecuta el env´ıo de datos, resoluci´on de direcciones y otras funciones de control para un sistema final dentro de 103

una ELAN. Tambi´en provee una interfaz est´andar para las entidades de nivel superior. Una NIC ATM o un switch LAN que es interfaz de una ELAN soporta un s´olo LEC por cada ELAN a la que est´e conectado. Los sistemas finales que se conecten a m´ ultiples ELANs tendr´an un LEC por ELAN. Cada LEC es identificado por una direcci´on ATM u ´nica, y es asociado con una o m´as direcciones MAC accesibles a trav´es de la direcci´on ATM. Servidor LANE o LES. Implementa la funci´on de control para una ELAN en particular. Existe un s´olo LES l´ogico por ELAN, y para pertenecer a una ELAN en particular se requiere establecer alguna relaci´on de control con el LES asociado a la ELAN. Cada LES es identificado con una direcci´on ATM u ´nica. Servidor de Broadcast y Desconocido o BUS. Es un servidor de multicast usado para inundar la red con el tr´afico de direcciones desconocidas y enviar tr´afico multicast y broadcast a los clientes de la ELAN. Cada LEC est´a asociado a un s´olo BUS por ELAN, pero existen m´ ultiples BUS dentro de una ELAN. El BUS al que se conecta el LEC es identificado por una direcci´on ATM u ´nica, que es asociada en el LES con la direcci´on de broadcast. Servidor de Configuraci´ on LANE o LECS. Es una entidad que asigna LECs a las ELANs, dirigi´endolos a un LES en particular. Existe un LECS l´ogico por dominio administrativo y sirve a todas las ELANs dentro del dominio. Las entidades definidas anteriormente se comunican entre s´ı usando dos tipos de conexiones, una para control de tr´afico y otra para transmisi´on de datos. Las conexiones de control son las siguientes (ver Figura 48): VCC de Configuraci´ on Directo. VCC bidireccional punto-a-punto desde LEC al LECS. VCC de Control Directo. VCC bidireccional punto-a-punto desde LEC al LES. VCC de Control Distribuido. VCC unidireccional desde LES al LEC, es t´ıpicamente puntoa-multipunto. Las conexiones de datos son las siguientes (ver Figura 49): VCC Directo de Datos. VCC bidireccional entre LECs que desean intercambiar datos. T´ıpicamente son conexiones ABR o UBR y no ofrecen soporte de QoS. 104

UNI LES 1

LNNI

Host ATM LES N

Red ATM Switch L. 2

BUS 1

LNNI

BUS N Router

LUNI LECS

Figura 47: Interfases del Protocolo LANE.

VCC Control Directo

LES

VCC Control Distribuido

VCC Control Directo

Switch L.2

Host ATM VCC Configuración Directa

LECS

VCC Configuración Directa

Figura 48: Conexiones de Control LANE.

VCC de Env´ıo de Multicast. VCC bidireccional punto-a-punto desde LEC al BUS. VCC de Reenv´ıo de Multicast. VCC unidireccional desde BUS al LEC. T´ıpicamente es una conexi´on punto-a-multipunto con cada LEC como hoja. Operaci´ on de LANE

105

BUS VCC Envío de Multicast

VCC Envío de Multicast VCC Reenvío de Multicast

Host ATM

VCC Directo de Datos

Switch L.2

Figura 49: Conexiones de Datos LANE.

Inicializaci´ on y Configuraci´ on En la inicializaci´on el LEC debe obtener su direcci´on ATM. Para esto el LEC establece una conexi´on de configuraci´on directa, ubicando la direccci´on del LECS de una de las siguientes tres maneras: usando un determinado procedimiento ILMI, usando una direcci´on de LECS conocida o usando una conexi´on a LECS conocida. Una vez encontrado el LECS, el LEC establece la conexi´on de configuraci´on directa y un protocolo de configuraci´on se usa para indicar al LEC de la informaci´on necesaria que requiere para conectarse a una ELAN (direcci´on ATM del LES, tipo de LAN emulada, tama˜ no m´aximo de los paquetes y nombre de la ELAN). Uni´ on y Registro Una vez que el LEC obtiene la direcci´on del LES, se debe establecer una conexi´on de control directa al LES, para que ´este asigne un identificador LEC (LECID). El LEC registra sus direcciones MAC y ATM. ´ El LES establece un enlace de control distribuido. Este u ´ltimo y el enlace de control directo pueden ser usados por el LEC para implementar la resoluci´on de direcciones con el procedimiento LANE ARP (LE ARP). Esto se lleva a cabo de la siguiente manera: el LEC solicita con un LE ARP una direcci´on al LES, que consulta su tabla y la devuelve por el VCC de control directo si la conoce, o por el de control distribuido si no la conoce, para que el que la sepa responda al LE ARP. Para completar el mecanismo de inicializaci´on, el LEC usa el LE ARP para determinar la direcci´on ATM del BUS, enviando al LES la direcci´on de broadcast MAC, a la que el LES responde con la direcci´on ATM del BUS. El LEC establece entonces la conexi´on de env´ıo 106

de multicast con el BUS, a la que el BUS responde con la conexi´on de reenv´ıo de multicast, a˜ nadiendo al LEC como una hoja nueva. Transferencia de Datos Durante la transferencia de datos el LEC recibe un paquete del nivel de red desde un protocolo de nivel superior o un paquete MAC a enviar a trav´es de un puerto, en el caso de los switches LAN. En primera instancia el LEC no conoce la direcci´on ATM del LEC destino. Para resolver esto env´ıa al LES un LE ARP. Mientras espera respuesta al LE ARP, el LEC env´ıa el paquete al BUS, usando alguna encapsulaci´on definida. El BUS enviar´a el paquete a todos los LECs. Si se recibe la respuesta al LE ARP, el LEC establece un VCC directo de datos con el nodo destino, y utiliza esa conexi´on para la transferencia de datos en vez de la trayectoria del BUS. Si ya exist´ıa una conexi´on directa con el LEC, en la misma ELAN, opcionalmente puede reutilizarse la conexi´on antigua, conservando recursos y evitando latencia de conexi´on. Si no se recibe respuesta al LE ARP, el LEC continuar´a enviando paquetes al BUS, pero regularmente enviar´a LE ARPs hasta recibir respuesta. Un LEC construir´a un cache de las direcciones MAC a ATM, para luego consultar sus propias tablas y as´ı aumentar el desempe˜ no del sistema, disminuyendo el tr´afico. El BUS tambi´en es utilizado por el LEC para enviar paquetes broadcast y multicast. Estos paquetes son enviados al BUS, que los reenv´ıa a todos los LECs. Debido a que algunos protocolos de nivel superior no toleran que se reciba una copia de un paquete propio, la encapsulaci´on requiere que todos los paquetes MAC contengan un LECID que permita a los LECs filtrar sus propios paquetes.

107

3.

Nivel de Red

3.1.

Introducci´ on

El principal objetivo de la capa de red es rutear, encaminar o dirigir los paquetes desde el ´ origen al destino. Esta es la u ´nica capa que “ve” y conoce la topolog´ıa de la red, y est´a formada por dos tipos de nodos: Nodos terminales. Generan o reciben paquetes de otros nodos, nunca rutean paquetes dirigidos a terceros. Nodos intermedios o de ruteo. Se utilizan para rutear paquetes entre los nodos terminales. Suelen ser arquitecturas dedicadas y dise˜ nadas espec´ıficamente para esa funci´on, con sistemas operativos en tiempo real, aunque en ocasiones tambi´en se utilizan para desempe˜ nar esta funci´on computadores normales.

Tabla 7: Denominaci´on de los tipos de nodos en diferentes redes Tipos de nodos Internet (IP) X.25 ATM ISO Nodo terminal

Host

DTE

Host

End System (ES)

Nodo intermedio o de ruteo

Router

DCE

Switches

Intermediate System (IS)

La terminolog´ıa de los dos tipos de nodos es muy diversa y var´ıa seg´ un el tipo de red y la “cultura” de que se trate. Aunque la terminolog´ıa no se puede dividir de forma estricta la Tabla 7 refleja las denominaciones m´as caracter´ısticas en algunos de los casos m´as habituales. Dado que la funci´on de los nodos intermedios es interconectar redes, normalmente tienen varias interfases f´ısicas, y los nodos terminales normalmente una. En cada interfaz f´ısica de un nodo funciona una instancia independiente del nivel f´ısico y del nivel de enlace, y por el contrario, el nivel de red es normalmente global para todo el nodo. Por ejemplo, en el caso de IP cada interfaz f´ısica tiene, al menos, una direcci´on de red, independientemente de que puedan tener varias. En una LAN Ethernet, todos los nodos terminales se comunican directamente entre s´ı usando los protocolos MAC, sin necesidad de nodos intermedios, por lo que la capa de red es innecesaria y generalmente es inexistente. Esto incluye el caso en que la LAN incluya bridges o switches de cualquier tipo. Debido a esto, el nivel de enlace tiene una complejidad mayor. Los bridges MAC, en especial los de encaminamiento desde el origen, desempe˜ nan una funci´on 108

hasta cierto punto equivalente a la de un nodo intermedio de nivel de red pues reenv´ıan la informaci´on entre los distintos segmentos LAN. Los servicios que ofrece el nivel de red deber´an en lo posible aislar al nivel de transporte de detalles tales como tipo de tecnolog´ıa f´ısica utilizada (LAN, WAN, broadcast, etc.), n´ umero y topolog´ıa de las subredes, etc. Las direcciones de red deber´an tener un formato homog´eneo, cualquiera sea el medio f´ısico o subred utilizados. Los servicios de red pueden ser orientados a conexi´on o no orientados a conexi´on. Ejemplos de servicios no orientados son el protocolo IP y el protocolo de red de ISO CLNP, elaborado a imagen y semejanza del IP. Ejemplos de servicios de red orientados a la conexi´on son ATM y X.25. En una red no orientada a la conexi´on, el nivel de transporte es normalmente m´as complejo pues ha de desempe˜ nar m´as funciones que en una red orientada a la conexi´on.

3.2.

Algoritmos de Ruteo

La funci´on fundamental de la capa de red es averiguar c´omo llegar con los datos desde el origen al destino, lo que en la pr´actica se traduce en que el nodo intermedio debe responder a la pregunta ¿por qu´e interfaz se han de enviar los paquetes recibidos?. Con redes basadas en datagramas esta decisi´on se toma para cada paquete y el nodo que la realiza se denomina router. Con redes orientadas a conexi´on, que son las basadas en circuitos virtuales, la decisi´on se toma en el momento de establecer el circuito virtual, y a partir de entonces s´olo conmutan paquetes. El mecanismo que permite elegir la ruta a utilizar es lo que se denomina algoritmo de ruteo, el que debiera ser ´optimo y justo. Estos conceptos a veces se contraponen, ya que el algoritmo que permite un aprovechamiento ´optimo de los recursos no siempre es el que ofrece el reparto m´as equitativo. Los algoritmos de ruteo se dividen en dos grupos: est´aticos y din´amicos. Los algoritmos est´aticos toman las decisiones utilizando informaci´on previamente recopilada sobre el estado de la red, en cambio los algoritmos din´amicos utilizan informaci´on recopilada en tiempo real sobre el estado de la red que se actualiza constantemente mediante paquetes que intercambian los routers a trav´es de la misma red. En el ruteo est´atico las rutas se fijan en funci´on de la capacidad de la l´ınea, el tr´afico medio u otros criterios similares. En cada router se cargan las tablas de rutas de forma est´atica, por lo que no necesita intercambiar informaci´on con sus vecinos, y por tanto, no se requiere un protocolo de ruteo. Con el ruteo est´atico no es posible responder a situaciones cambiantes,

109

por ejemplo, saturaci´on, exceso de tr´afico o fallo de una l´ınea. Al realizar los c´alculos de las rutas ´optimas en diferido es posible aplicar algoritmos sofisticados, aun cuando requieran gran cantidad de recursos de c´alculo o de memoria. En el ruteo din´amico, las rutas ´optimas se recalculan continuamente en funci´on de la informaci´on que los routers reciben en tiempo real sobre el estado de la red. Se utilizan algoritmos autoadaptativos y es preciso utilizar un protocolo de routing que permita a los routers intercambiar continuamente esa informaci´on. Los algoritmos no pueden ser demasiado complejos pues han de implementarse en los routers y ejecutarse en tiempo real con los recursos de CPU y memoria de que el router dispone. 3.2.1.

El Principio de Optimalidad

Si B est´ a en la ruta ´ optima de A a C, entonces el camino ´ optimo de B a C est´ a incluido en dicha ruta. Una consecuencia importante de este principio es que todas las rutas ´optimas para llegar a un punto determinado forman un ´arbol con ra´ız en el punto de destino. Si el ´arbol no contiene loops, se dice que es un spanning tree y siempre es posible llegar al punto de destino en un n´ umero finito de saltos o hops. 3.2.2.

Ruteo por el Camino M´ as Corto y M´ etricas

Existen diversos algoritmos que permiten calcular el camino m´as corto entre dos nodos de un grafo. Uno de los m´as conocidos es el algoritmo de Dijkstra, y se utiliza tanto en routing est´atico como din´amico. Para saber elegir el camino m´as corto primero se debe definir que se entiende por distancia. En los casos m´as simples la distancia se mide como el n´ umero de saltos o hops, donde, a mayor n´ umero de saltos mayor distancia. Evidentemente esto es satisfactorio u ´nicamente en casos muy simples en que todos los enlaces tiene la misma capacidad. Normalmente la distancia se mide como una combinaci´on de los siguientes factores: El inverso de la capacidad del enlace (informaci´on est´atica). Tr´afico medio (puede ser informaci´on est´atica o din´amica). Retardo (informaci´on din´amica medida a partir de los paquetes enviados).

110

El inverso de la confiabilidad (informaci´on din´amica medida a partir de los paquetes enviados). El peso relativo que se da a cada uno de los factores que intervienen en el c´alculo de la distancia en una red se denomina m´etrica. La m´etrica puede ser fijada o modificada al configurar los router, aunque los par´ametros que entran en juego y la f´ormula que se utiliza para calcularla suelen estar muy relacionados con el algoritmo y el protocolo de routing utilizados. Cuando un trayecto est´a compuesto por varios tramos la longitud o distancia del trayecto ser´a igual a la suma de las distancias de los tramos que lo componen. Cuando el par´ametro utilizado para el c´alculo de la distancia es invariante en el tiempo, por ejemplo velocidad del enlace, puede aplicarse a un algoritmo de ruteo est´atico. Se podr´ıa cargar en un computador toda la informaci´on sobre la topolog´ıa de la red y calcular las rutas ´optimas para cada caso, y una vez obtenidas ´estas se cargar´ıan en todos los routers de la red. Si se emplean adem´as par´ametros din´amicos como retardo o confiabilidad, puede utilizarse un algoritmo din´amico. En este caso la informaci´on se propaga en toda la red y los c´alculos se hacen de manera descentralizada entre todos los routers. 3.2.3.

Ruteo Basado en el Flujo

Este algoritmo toma en cuenta la cantidad de tr´afico medio que soportan las l´ıneas, y en base a esta informaci´on intenta optimizar el conjunto de las rutas para utilizar el camino menos congestionado en cada caso. Para aplicarlo se ha de conocer bastante bien el tr´afico, y ´este ha de ser muy regular. Se pueden aplicar algoritmos relativamente sofisticados ya que el c´alculo de rutas se hace offline y se carga en el router despu´es. Este algoritmo s´olo se aplica en algunos casos de routing est´atico. Puede ser u ´til para dise˜ nar la topolog´ıa de una red. Por ejemplo, si se conectan una serie de oficinas y se dispone de la matriz de tr´afico previsto entre cada par de oficinas se pueden plantear diversas topolog´ıas y estudiar cu´al es la m´as adecuada. 3.2.4.

Flooding

La inundaci´on o flooding consiste en enviar cada paquete por todas las interfases, excepto ´ por la que se ha recibido. Esta t´ecnica se aplica en los frames de descubrimiento en los bridges por encaminamiento desde el origen y en los puentes transparentes cuando la direcci´on de destino era desconocida. 111

La inundaci´on puede multiplicar el tr´afico si existen loops en la topolog´ıa, ya que en ese caso se env´ıan paquetes duplicados. Para limitar este problema se fija un n´ umero m´aximo de saltos, que suele ser igual al n´ umero de saltos que hay entre los dos puntos m´as alejados de la red. Otra posibilidad es identificar los paquetes, por ejemplo numer´andolos, para que cada router mantenga una lista de los paquetes enviados y as´ı puede evitar reenviarlos de nuevo. Tambi´en puede usarse flooding selectivo en el que el paquete se env´ıa s´olo por las l´ıneas que aproximadamente apuntan en la direcci´on correcta. Flooding se utiliza en algunos algoritmos de routing multicast. 3.2.5.

Ruteo por Vector de Distancia

Este algoritmo se aplica en diversos protocolos de routing. Tambi´en se conoce como algoritmo de Bellman-Ford o Ford-Fulkerson, que fueron los autores de la idea. Fue el algoritmo original de ARPANET, se utiliz´o en DECNET, IPX y Appletalk. Se usa en el protocolo RIP, que hasta 1988 era el u ´nico protocolo de ruteo utilizado en Internet. Tambi´en se utiliza en los protocolos propietarios IGRP y EIGRP de Cisco. En el ruteo por vector distancia cada router mantiene una tabla o vector que le indica la distancia m´ınima conocida hacia cada posible destino y que l´ınea o interfaz debe utilizar para llegar a ´el. La tabla se actualiza regularmente con informaci´on obtenida de los routers vecinos. Cada router env´ıa la tabla completa de distancias a todos sus vecinos, y s´olo a ellos. Con la informaci´on que tiene y la recibida de sus vecinos cada router recalcula continuamente su tabla de distancias. La m´etrica a utilizar puede ser n´ umero de saltos, retardo, paquetes encolados, etc. o una combinaci´on de ´estos u otros par´ametros. Para medir el retardo el router env´ıa paquetes de prueba que deben ser respondidos por el router remoto. Cada router s´olo mide el retardo con sus vecinos, los retardos y distancias a routers m´as lejanos los calcula como suma de la distancia a sus vecinos m´as la informaci´on que ´estos le facilitan. Esta clase de algoritmo es f´acil de implementar, pero tiene un algunas desventajas considerables. Por ejemplo, cuando las rutas cambian r´apidamente, como en el caso de producirse fallas o ca´ıdas de enlaces, la topolog´ıa de red puede no estabilizar las rutas que han cambiado debido a que la informaci´on se propague lentamente y mientras se est´e propagando, algunos routers tendr´an informaci´on incorrecta. En este tipo de algoritmos, la tarea m´as dif´ıcil es prevenir la inestabilidad.

112

A B

C

D

Red Destino

Figura 50: El Problema de la Cuenta Hasta Infinito.

El Problema de la Cuenta Hasta Infinito. Suponer que una red se vuelve inestable, y todos sus vecinos generan un timeout y fijan la m´etrica de esa red en el valor infinito (en la pr´actica un valor grande) para indicar que no es la mejor ruta o que ella est´a abajo. Se puede considerar entonces que todos los routers vecinos tienen alguna interfaz que los conecta con la red desaparecida, a una m´etrica o costo infinito. Ya que se trata de la u ´nica conexi´on con esa red, el resto de los routers converger´a hacia nuevas rutas que pasen por los vecinos con una conexi´on directa pero no disponible. Una vez que se ha producido la convergencia, todos los routers tendr´an una m´etrica infinita para la red desaparecida quedando inaccesible para todos. De aqu´ı que la cuesti´on tras los algoritmos de vector distancia no sea si se producir´a la convergencia, sino cu´anto tiempo llevar´a. Considerar la configuraci´on mostrada en Figura 50 donde todos los enlaces tienen una m´etrica de 1 excepto por la ruta indirecta de C a D que tiene m´etrica de 10. Por lo tanto, las rutas para llegar a la red destino ser´an las siguientes: en el router D la conexi´on es directa, m´etrica 1; en el router B el siguiente salto es D, m´etrica 2; en el router C el siguiente salto es B, m´etrica 3 y en el router A el siguiente salto es B, m´etrica 3. Es decir, un paquete que desea llegar a la red destino y est´a en el router C, debe reenviarse por la interfaz que lo lleva a al router B, pues por ah´ı alcanzar´a el destino, que est´a a una m´etrica 3 de distancia. Si el enlace de B a D falla, entonces ese enlace es marcado con m´etrica infinito, por lo que las rutas se deber´ıan ajustar para utilizar de menor m´etrica, que ser´ıa el enlace de C a D. Los cambios en la informaci´on de ruteo comienzan entonces cuando B se da cuenta de que la ruta D ya no es utilizable. El problema es que B se puede liberar de su ruta marc´andola con m´etrica infinito, pero a´ un 113

quedan vestigios de esa ruta en el sistema durante mucho tiempo. Lo anterior se explica pues inicialmente, A y C todav´ıa piensan que pueden alcanzar a la red D usando B, as´ı que siguen enviando actualizaciones con m´etricas de 3. B las recibir´a y, en la siguiente iteraci´on, dir´a que puede llegar a D, pero ahora con una m´etrica 4. Por supuesto, nunca podr´a llegar a D, ya que las rutas enviadas por A y C para alcanzar D son v´ıa el router B, cuya ruta ya no est´a producto de la falla, pero para los otros routers todav´ıa no hay forma de saberlo, pues B nunca propag´o la informaci´on. M´as a´ un, cuando descubren que sus rutas por B han desaparecido, todav´ıa piensan que hay una ruta disponible a trav´es del otro (A o C). Por otro lado, cuando B env´ıa su nueva actualizaci´on, ´esta dice que para alcanzar la red destino, el siguiente salto ser´a, por ejemplo C, con m´etrica 4. Esta informaci´on ser´a recibida por A y C, que notar´an que hay un cambio de m´etrica para llegar a destino, por lo que aumentar´an su m´etrica a 5 (pues para llegar a D su siguiente salto es B) y as´ı la situaci´on continuar´a aumentando los valores de m´etrica. Al final, el sistema converger´a cuando el enlace directo de C a D tenga menor m´etrica que el recibido, en este caso por C, de B a A. El peor caso ocurre cuando una red se vuelve completamente inaccesible desde alguna parte del sistema: en este caso, las m´etricas se pueden incrementar lentamente de modo parecido al indicado hasta que finalmente alcancen el valor infinito. De esta forma, la elecci´on de la infinidad es un compromiso entre el tama˜ no de la red y la velocidad de convergencia en el caso de que la cuenta se produzca. 3.2.6.

Ruteo por Estado del Enlace

El ruteo basado en el estado del enlace apareci´o como un intento de resolver los problemas que planteaba el ruteo por vector distancia, fundamentalmente el problema de la cuenta a infinito. Se trata de un algoritmo m´as sofisticado y robusto, compuesto por cuatro fases: 1. Descubrir los routers vecinos y averiguar sus direcciones. Esto se hace mediante el env´ıo de paquetes HELLO por todas sus interfases. Los paquetes HELLO son respondidos con mensajes que identifican a los routers que los reciben. 2. Medir el retardo o costo de llegar a cada vecino. Para esto, se env´ıan paquetes de ECHO que son respondidos por el router remoto y miden el tiempo de ida y vuelta. 3. Construir un paquete que resuma toda esta informaci´on, y enviarlo a todos los routers de la red. Se utiliza flooding, y los paquetes se numeran para detectar y descartar duplicados, e ignorar paquetes obsoletos. Adem´as, cada paquete tiene una vida limitada, al cabo de la cual es descartado. 114

4. Calcular el camino m´as corto a cada router. Con toda la informaci´on obtenida el router construye el ´arbol de expansi´on de las rutas ´optimas a cada destino de la red aplicando el algoritmo de Dijkstra. De esta forma conoce la topolog´ıa de la red. Entre los protocolos de routing que utilizan algoritmos basados en el estado del enlace destaca OSPF (Open Shortest Path First) que es el protocolo de ruteo est´andar de Internet. Otro protocolo de estado del enlace tambi´en utilizado en Internet y que proviene de OSI es IS-IS (Intermediate System-Intermediate System). IS-IS es multiprotocolo, es decir, soporta m´ ultiples protocolos de red por encima. OSPF esta basado en IS-IS, pero no es multiprotocolo. En el routing por el vector distancia cada router env´ıa informaci´on s´olo a sus vecinos, pero esta informaci´on incluye a todos los nodos de la red. En cambio en el routing por el estado del enlace cada router env´ıa su paquete de informaci´on a toda la red, pero ´este solo contiene la relativa a sus vecinos m´as pr´oximos. En el estado del enlace cada router puede, a partir de la informaci´on obtenida, conocer su ´arbol de expansi´on completo, mientras que esto no es posible con routing por el vector distancia. 3.2.7.

Ruteo Jer´ arquico

A medida que una red crece la cantidad informaci´on de routing aumenta de forma exponencial, ya que cada router ha de calcular las rutas ´optimas a todos los dem´as. Esto incrementa el tr´afico, la memoria en los routers, y la complejidad de los c´alculos necesarios para obtener las rutas ´optimas. Como consecuencia de esto los algoritmos de routing no son escalables. Para reducir este problema las redes se organizan en niveles jer´arquicos. Se divide la red en regiones o sistemas aut´onomos, y s´olo un n´ umero reducido de routers de cada regi´on se puede comunicar con el exterior. Las rutas quiz´a no sean tan ´optimas, pero se simplifica la administraci´on y mantenci´on de las tablas y se reduce el tr´afico de la red. 3.2.8.

Ruteo Broadcast

En algunos casos se necesita enviar un paquete a todos los destinos posibles en una red, es decir se quiere hacer un env´ıo broadcast. Esto puede hacerse por flooding, pero se pueden producir loops en la red. Para evitarlo se suele poner al paquete un contador de saltos con un l´ımite igual al di´ametro de la red. Otro m´etodo es el ruteo multidestino, que consiste en enviar un u ´nico paquete con todas las direcciones de destino. El paquete es replicado en cada router por las interfases por donde debe enviarse, es decir, las que son parte de la mejor ruta para alguno de los destinos indicados. 115

Otro algoritmo es construir el ´arbol de expansi´on o spanning tree con ra´ız en el origen y seguirlo, replicando el paquete donde haya una bifurcaci´on. El sistema es ´optimo, ya que se asegura que la distribuci´on se har´a generando el n´ umero m´ınimo de paquetes y sin env´ıos duplicados, pero esto requiere que cada router conozca cuales de sus interfases forman parte del spanning tree para el router origen y cuales no, es decir, los routers han de conocer en detalle la topolog´ıa de la red. Por u ´ltimo, el algoritmo de ruteo por el camino inverso es una aproximaci´on al spanning tree cuando la informaci´on sobre la topolog´ıa no est´a disponible. El mecanismo es el siguiente: el router examina la direcci´on origen del paquete recibido, y la interfaz por la que le ha llegado. Si esa interfaz es el camino m´as corto para llegar a esa direcci´on es bastante probable que el paquete no sea un duplicado, por lo que lo reenviar´a por todas las interfases excepto por aquella por la que vino. Si no lo es, el paquete se descarta pues es muy probable que sea un duplicado. Esta t´ecnica evita que se produzcan loops y consigue una eficiencia bastante buena, aunque no es ´optima ya que se generan algunos env´ıos duplicados. 3.2.9.

Ruteo Multicast

Para el env´ıo de paquetes multicast primero hay que crear el grupo multicast. Una vez creado el grupo, los usuarios pueden unirse al ´el o abandonarlo. Cuando un usuario se une a un grupo multicast debe informar a su router y ´este a sus vecinos. En una LAN el env´ıo de paquetes multicast no plantea ning´ un problema desde el punto de vista del routing, ya que simplemente se env´ıan los paquetes a la red y ser´an captados por aquellas estaciones que pertenezcan al grupo. En una WAN, cada router que quiera enviar paquetes multicast ha de construir el spanning tree de toda la subred, coloc´andose ´el como ra´ız. A continuaci´on, deja s´olo las ramas necesarias para hacer llegar los paquetes a los routers que forman parte del grupo multicast. Si se utiliza ruteo de estado de enlace cada router conoce la topolog´ıa de la red, por lo que puede generar el ´arbol sin problemas, de abajo hacia arriba. Con vector de distancia se puede utilizar ruteo por camino inverso. Existen dos estrategias posibles para construir el ´arbol de expansi´on de una distribuci´on multicast. La primera, conocida como modo denso la emisi´on multicast se env´ıa en principio a todas las ramas del ´arbol y ´esta se va limitando a algunas ramas s´olo a medida que los routers lo solicitan. La segunda, denominada modo disperso consiste en que la emisi´on solo se realiza por aquellas ramas cuyos routers lo han solicitado. La segunda estrategia es m´as conveniente cuando el n´ umero de miembros es reducido en proporci´on a las ramas del ´arbol. 116

Para que el modo disperso pueda funcionar correctamente es preciso que haya un servicio de anuncio de sesiones disponibles de forma que los que no reciben la emisi´on multicast sepan de su existencia.

3.3.

Algoritmos de Control de Congesti´ on

Congesti´ on: situaci´on en la que el rendimiento de la red, o una parte de ella, se degrada debido a la presencia de tr´afico excesivo. No se debe confundir la congesti´on con el control de flujo. A diferencia de la congesti´on, el control de flujo es una circunstancia que s´olo puede darse en conexiones punto a punto, es decir, a nivel de enlace o a nivel de transporte. Una de las posibles consecuencias del control de congesti´on es ejercer control de flujo sobre ´el o los nodos que est´an produciendo la congesti´on. La congesti´on es generalmente un problema m´as complejo que el control de flujo, ya que generalmente el emisor del tr´afico es un router, es decir un intermediario que lo m´as que puede hacer es reenviar el mensaje de control de congesti´on hacia atr´as. Generalmente, cuando el mensaje llega al verdadero causante de la congesti´on el tr´afico ya ha cesado y resulta in´ util tomar medidas. Este problema se acent´ ua especialmente en redes de alta velocidad y elevado retardo (gran distancia). 3.3.1.

Principios Generales del Control de Congesti´ on

Para el control de la congesti´on caben dos planteamientos: Dise˜ nar las cosas desde el principio para que la congesti´on no pueda llegar a ocurrir. Tomar medidas que permitan detectar la congesti´on y adoptar medidas correctoras en su caso. La primera t´ecnica es m´as segura, pero puede provocar ineficiencias si se aplican las limitaciones con demasiada severidad. La segunda permite aprovechar mejor la red, pero en caso de congesti´on puede ser dif´ıcil controlar la situaci´on. Entre los par´ametros que permiten detectar la presencia de congesti´on, a nivel de red, se encuentran: Porcentaje de paquetes descartados. Longitud media de las colas en las interfases de los routers.

117

En cambio, a nivel de transporte se tiene: Retardo medio por TPDU (Transport Protocol Data Unit). Desviaci´on media del retardo por TPDU (jitter). N´ umero de TPDUs que se pierden o llegan al timeout y se retransmiten (se supone que esto no se debe a errores). Para informar sobre situaciones de congesti´on el receptor puede utilizar paquetes de alerta y el emisor enviar paquetes de sondeo para averiguar el estado de la red. Para resolver la congesti´on solo hay dos posibles medidas: Reducir el tr´afico solicitando al emisor que pare de transmitir, o que busque rutas alternativas. Aumentar la capacidad. 3.3.2.

Factores que Influyen en la Congesti´ on

Entre los factores, a nivel de enlace, que pueden influir en la congesti´on se encuentran: El intervalo de timeout, ya que si es peque˜ no originar´a retransmisiones innecesarias. El tama˜ no de ventana. Si es grande es m´as f´acil que se produzca congesti´on. El uso de retroceso n o repetici´on selectiva. El retroceso n genera m´as tr´afico. El uso o no de ACK piggybacked. Si no se usa se genera m´as tr´afico. En el nivel de red, los factores que influyen en la congesti´on son los siguientes: Uso de circuitos virtuales o datagramas. Existe mejor control de congesti´on cuando se trata de circuitos virtuales. Uso de mecanismos de encolamiento y criterios de selecci´on o prioridades. Uso de mecanismos de descarte de paquetes. Algoritmo de ruteo. Vida media de los paquetes o timeout. Si es muy peque˜ na, tendr´an que ser retransmitidos, si es excesiva terminar´an siendo in´ utiles. 118

En el nivel de transporte se dan b´asicamente los mismos factores que en el nivel de enlace, la principal diferencia es que la estimaci´on del timeout adecuado es mucho m´as dif´ıcil al no ser una comunicaci´on entre entidades vecinas. 3.3.3.

Traffic Shaping y Traffic Policing

El tr´afico de r´afagas o bursty es la principal causa de congesti´on. Si todos los nodos transmitieran siempre un flujo constante ser´ıa muy f´acil evitar las congestiones. En el traffic shaping, se establece m´argenes m´aximos al tr´afico a r´afagas. Suelen utilizarse para fijar una calidad de servicio o QoS entre el operador y el usuario. Mientras el usuario respete lo establecido, el operador se compromete a no descartar paquetes. El perfil de tr´afico act´ ua entonces como una especie de contrato entre las partes. El traffic policing corresponde a una labor de monitoreo o seguimiento del tr´afico introducido por el usuario en la red para verificar que no excede el perfil pactado. Uno de los sistemas m´as utilizados para establecer perfiles de tr´afico es el algoritmo de leaky bucket. El host puede enviar r´afagas que son almacenadas en un buffer de la interfaz, la que env´ıa a la red un flujo constante de salida. Si la r´afaga es de tal intensidad o duraci´on que el buffer se llena, los paquetes excedentes son descartados, o bien son enviados a la red con una marca especial que les identifica como de segunda clase. Estos paquetes ser´an los primeros candidatos a descarte en caso de congesti´on. Para definir el algoritmo se utilizan dos par´ametros, el flujo r con que sale el flujo a la red, y la capacidad del buffer C. Esta t´ecnica se utiliza en ATM y en Frame Relay y se est´a proponiendo su introducci´on en IP. M´as a´ un, en el kernel 2.4.X de Linux se puede hacer traffic shaping con algunos simples comandos en la configuraci´on de las interfases de red y definiendo una nueva interfaz llamada shaper (Ver, por ejemplo, http://linux.oreillynet.com/pub/a/linux/2000/08/24/LinuxAdmin.html). La Figura 51 muestra un caso real de traffic shaping, en el que se filtr´o una conexi´on entre dos m´aquinas. La sesi´on de FTP (l´ınea roja) que se llev´o a cabo, en primer lugar no fue filtrada con traffic shaping, y corresponde a la situaci´on que se observa en primer lugar a la izquierda de la imagen, donde existe un peak bastante considerable en la transmisi´on, cercano a las 9000 celdas/seg (unos 3.8 Mbps). A continuaci´on, se repiti´o la experiencia haciendo traffic shaping de 300 kbps de salida, y se observa (en la parte derecha) que la imagen que ahora el tiempo involucrado en la transferencia es mucho mayor, pero la tasa de transferencia se satura alrededor de las 700 celdas/seg (unos 296 kbps). Un nodo que est´e continuamente transmitiendo con un flujo r mantendr´a vac´ıo su buffer y a la hora de enviar una r´afaga estar´a en igualdad de condiciones respecto a otro nodo que 119

Figura 51: Ejemplo real de Traffic Shaping en una red ATM.

no haya transmitido nada durante cierto tiempo. El algoritmo token bucket es una versi´on mejorada del anterior que compensa al host que alterna intervalos de tr´afico con otros de inactividad frente al que esta siempre transmitiendo. El mecanismo que sigue para ello es el siguiente: cuando el host no env´ıa datos el pozal va sumando cr´editos o tokens hasta un m´aximo igual a la capacidad del buffer. Los cr´editos acumulados pueden utilizarse despu´es para enviar r´afagas con un flujo M mayor de lo normal. Cuando se agotan los cr´editos, el flujo vuelve a su valor normal r y el algoritmo funciona como un leaky bucket. Los par´ametros que definen este algoritmo son el flujo normal r, la capacidad del buffer C y el flujo m´aximo M que normalmente igual a la velocidad de la interfaz f´ısica. 3.3.4.

Control de Admisi´ on

El control de admisi´on se aplica u ´nicamente a las redes orientadas a conexi´on y consiste en evitar el establecimiento de nuevos circuitos virtuales que pasen por una zona de la red que se considera congestionada. Si se conoce la capacidad m´axima que necesita cada circuito virtual en principio es posible controlar el acceso de forma que nunca se produzca congesti´on. 120

Generalmente un control de admisi´on estricto no usa los recursos de manera eficiente ya que al reservar para cada circuito la capacidad m´axima la red se encuentra subutilizada la mayor parte del tiempo. 3.3.5.

Choke Packets

Los choke packets o paquetes de asfixia se puede aplicar tanto en redes de circuitos virtuales como de datagramas. En esta t´ecnica el router comprueba regularmente cada una de sus l´ıneas, monitoreando, por ejemplo, el grado de utilizaci´on, la longitud de la cola o la ocupaci´on del buffer correspondiente. Cuando el par´ametro inspeccionado supera un determinado valor considerado umbral de peligro se env´ıa un choke packet al host considerado culpable para que reduzca el ritmo. Los paquetes de asfixia tienen el riesgo de producir comportamientos oscilatorios, ya que cuando se percibe una situaci´on peligrosa se env´ıan avisos que pueden bloquear a todos los emisores. Al detectar que el problema est´a resuelto se pide reanudar los env´ıos, con lo que hay riesgo de caer nuevamente en la situaci´on de alerta, y as´ı sucesivamente. Normalmente los paquetes de asfixia se env´ıan a los hosts que generan el tr´afico, ya que son ´estos y no los routers los verdaderos causantes de la congesti´on. Los hosts cuando reciben estos paquetes suelen reducir, t´ıpicamente a la mitad, la velocidad con la que env´ıan datos a la red. 3.3.6.

Descarte de Paquetes

El u ´ltimo recurso para resolver un problema de congesti´on es descartar paquetes. En ocasiones los paquetes llevan alguna indicaci´on de su grado de importancia, en cuyo caso los routers intentan descartar los menos importantes primero. Por ejemplo, ser´ıa bastante grave si un router para resolver una situaci´on de congesti´on descartara paquetes de asfixia. A veces el nivel de aplicaci´on puede dar informaci´on sobre la prioridad de descarte de los paquetes. Por ejemplo, en aplicaciones de tiempo real suele ser preferible descartar el paquete viejo al nuevo ya que el viejo seguramente es in´ util. Por el contrario, en la transferencia de archivos el receptor necesita recibir todos los paquetes, y el m´as antiguo causar´a antes la retransmisi´on por timeout. En algunos casos el paquete transmitido por la red es parte de una secuencia correspondiente a otro paquete de mayor tama˜ no que viaja fragmentado. En estos casos si se descarta un paquete cualquiera de una secuencia se tendr´a que reenviar todo el grupo, por lo que al

121

descartar uno es conveniente descartar todos los dem´as ya que son tr´afico in´ util.

3.4.

El Protocolo IP

Internet es un conjunto de redes diferentes que comparten una pila de protocolos comunes. Cada una de estas redes es administrada por una entidad diferente: universidades, redes acad´emicas nacionales, ISPs (Internet Service Providers), operadores, empresas multinacionales, etc. Como consecuencia, de esto las pol´ıticas de uso son muy variadas. T´ecnicamente a nivel de red Internet puede definirse como un conjunto de redes o sistemas aut´onomos conectados entre s´ı que utilizan el protocolo de red IP. IP es una red de datagramas, no orientada a conexi´on, con servicio “best effort”, es decir, no ofrece QoS. La entrega de los paquetes no est´a garantizada ya que en momentos de congesti´on ´estos pueden ser descartados sin previo aviso por los routers que se encuentren en el trayecto. Version

IHL

Tipo de Servicio

Largo Total D M F F

Identificación TTL

Protocolo

Offset del Fragmento Checksum

Dirección Fuente Dirección Destino

Opciones (0 o más palabras)

32 bits

Figura 52: Encabezado del Paquete IP.

En una red IP toda la informaci´on viaja en unidades de informaci´on denominadas paquetes IP. Es decir, tanto la informaci´on de control que tenga que intercambiarse (routing din´amico, mensajes de error, etc.) como los datos de nivel superior, viajan de la misma forma, usando un servicio no orientado a la conexi´on. El paquete IP (ver Figura 52) tiene dos partes: encabezado y datos del nivel superior. El encabezado tiene una parte fija de 20 bytes y una opcional que va entre 0 y 40 bytes, pero siempre es un m´ ultiplo de 4. Los campos son los siguientes:

122

Versi´ on. 4 bits que permiten codificar los valores de las distintas versiones de IP. La versi´on actualmente en uso es la 4, pero desde hace alg´ un tiempo se empez´o ya a extender el uso de la versi´on 6 con una estructura de paquete diferente al de la Figura. IHL. 4 bits que especifican la longitud del encabezado, debido a que ´este puede variar por la presencia de campos opcionales. Se codifica en palabras de 32 bits (4 Bytes), donde la longitud m´ınima es 5 y la m´axima 15, que equivale a 40 bytes de informaci´on opcional. La longitud del encabezado siempre es un m´ ultiplo de 32 bits, por lo que se puede a˜ nadir un relleno al final del encabezado. Tipo de Servicio. 1 Byte. Permite establecer que calidad de servicio requiere el paquete. Se pueden establecer varios tipos de confiabilidad y velocidad (por ejemplo, rapidez en vez de confiabilidad para aplicaciones como audio o video, confiabilidad para transferencia de archivos, etc.). Este campo tiene subcampos de importancia: P (precedencia) son 3 bits de prioridad, un Flag tres bits D, T y R que permite especificar que importa m´as Retardo, Throughput o Confiabilidad. Recientemente, el campo Differentiated Services ha sustituido a este campo. Su finalidad es implementar QoS en redes IP mediante la arquitectura denominada Servicios Diferenciados o Diffserv. Largo Total. 2 Bytes que especifican la longitud del paquete completo, encabezado incluido, en bytes. Identificaci´ on. 2 Bytes. Este campo permite al destino determinar a que paquete pertenece el fragmento que ha llegado a ´el. Est´a relacionado con la fragmentaci´on de paquetes. DF. 1 bit, que indica no fragmentar el paquete. MF. 1 bit, indica que vienen m´as fragmentos. Todos los fragmentos que pertenecen a un mismo paquete, salvo el u ´ltimo, tienen este bit en 1. Offset del Fragmento. 13 bits para indicar a que parte, del paquete total, pertenece el fragmento que se est´a recibiendo. TTL. 1 Byte que permiten descartar un paquete una vez que ha dado un n´ umero excesivo de saltos o ha pasado un tiempo excesivo viajando por la red. Es un contador regresivo que indica el tiempo de vida restante del paquete, y su valor est´a medido en segundos, de forma al llegar a cero el paquete debe ser descartado. Esto permite evitar que se produzcan loops y un paquete pueda permanecer “flotando” indefinidamente en la red. 123

Como no resulta simple calcular con precisi´on el tiempo que un paquete emplea en el tr´ansito entre dos routers, en la pr´actica lo que se hace es restar el TTL en uno por cada salto, y en caso de que el paquete se encuentre durante m´as de un segundo esperando en un router, se resta uno por cada segundo de espera. Como los paquetes casi nunca est´an m´as de un segundo en un router, en realidad, este par´ametro funciona como un contador de saltos. En el caso de producirse fragmentaci´on, el host receptor puede retener paquetes durante varios segundos, mientras espera a recibir todos los fragmentos. En este caso, el host restar´a uno del TTL por cada segundo de espera, pudiendo llegar a descartar paquetes por este motivo. Los valores de TTL t´ıpicos est´an entre 64 y 128. Protocolo. 1 Byte que especifican a que protocolo de nivel de transporte corresponde el paquete. La tabla de protocolos v´alidos y sus correspondientes n´ umeros son controlados por el IANA (Internet Assigned Number Authority, http://www.iana.org/)la Tabla 8 muestra algunos de los posibles valores de este campo. Llama la atenci´on el valor 4 de la Tabla 8 que est´a reservado para el uso de IP para transportar IP, es decir, el hacer un t´ unel de un paquete IP dentro de otro. Esta t´ecnica permite realizar ruteo desde el origen de los paquetes encapsulando el paquete en otro dirigido al nodo intermedio por el que se quiere pasar. Una t´ecnica similar se sigue para hacer un tunneling de IP versi´on 6 en IP versi´on 4. Checksum. 2 Bytes que sirven para detectar errores en el encabezado del paquete. El checksum permite evitar al paquete de una alteraci´on en alguno de los campos del encabezado que pudiera producirse, por ejemplo, por un problema de hardware en un router. El checksum s´olo cubre el encabezado del paquete, no los datos. El campo checksum se ha de recalcular en cada salto, ya que al menos el TTL cambia. Notar que en routers con alto tr´afico, el volver a calcular del checksum supone un inconveniente desde el punto de vista de rendimiento. Direcci´ on Fuente. 4 Bytes que corresponden a la direcci´on IP origen. Direcci´ on Destino. 4 Bytes que corresponden a la direcci´on IP destino. Opciones. campo de longitud variable que no siempre est´a soportado en los routers y se utiliza muy raramente. Fue dise˜ nado para permitir expansiones al protocolo, experimentos, etc. Las opciones son de tama˜ no variable, comenzando siempre por un byte

124

de codificaci´on, y siempre son rellenadas a m´ ultiplos de 4 bytes. Entre las opciones se cuentan: Record Route que pide a cada router por el que pasa el paquete que anote en el encabezado su direcci´on, obteni´endose un trazado de la ruta seguida (debido a la limitaci´on a un m´aximo de 40 bytes en la parte opcional del encabezado, como m´aximo pueden registrarse 9 direcciones). Timestamp act´ ua de manera similar a record route, pero adem´as de anotar la direcci´on IP de cada router atravesado se anota en otro campo de 32 bits el instante en que el paquete pasa por dicho router. El uso de dos campos de 32 bits aumenta el problema antes mencionado, del poco espacio disponible para grabar esta informaci´on. Source Routing permite al emisor especificar la ruta que debe seguir el paquete hasta llegar a su destino. Existen dos variantes: strict source routing que especifica la ruta exacta salto a salto, de modo que si en alg´ un caso la ruta marcada no es factible por alg´ un motivo, se producir´a un error. La segunda es loose source routing donde se establece claramente los routers por los que debe pasar el paquete, pero se da libertad a la red para que use otros routers cuando lo considere conveniente. La limitaci´on en la longitud de las opciones impone un l´ımite m´aximo en el n´ umero de saltos que pueden especificarse. El uso de los campos opcionales del encabezado IP tiene generalmente problemas de rendimiento, ya que las implementaciones de los routers optimizan el c´odigo para las situaciones normales, es decir, para paquetes sin campos opcionales. Las opciones est´an implementadas y funcionan, pero lo hacen generalmente de forma poco eficiente ya que en el dise˜ no del software no se ha hecho ´enfasis en su optimizaci´on.

3.4.1.

Fragmentaci´ on

El tama˜ no de un paquete IP se especifica en un campo de dos bytes, por lo que su valor m´aximo es de 65535 bytes. Sin embargo, muy pocos protocolos o tecnolog´ıas a nivel de enlace admiten enviar frames de semejante tama˜ no. Normalmente, el nivel de enlace no fragmenta, por lo que tendr´a que ser IP el que adapte el tama˜ no de los paquetes para que quepan en los frames del nivel de enlace. Por lo tanto, en la pr´actica el tama˜ no m´aximo del paquete viene determinado por el tama˜ no m´aximo del frame caracter´ıstico de la red utilizada. Este tama˜ no m´aximo de paquete se conoce como MTU o Maximum Transfer Unit. La Tabla 9 muestra algunos valores caracter´ısticos de MTU de las tecnolog´ıas de redes m´as usadas. Existen dos situaciones en que se produce fragmentaci´on. La primera, denominada fragmentaci´ on en ruta, se produce cuando un paquete es creado por un host en una red con un 125

Tabla 8: Algunos Valores y Significados del Campo Protocolo en un Paquete IP Valor Protocolo Descripci´on 0

Reservado

1

ICMP

Internet Control Message Protocol

2

IGMP

Internet Group Management Protocol

3

GGP

Gateway-to-Gateway Protocol

4

IP

IP en IP (encapsulado)

5

ST

Stream

6

TCP

Transmission Control Protocol

8

EGP

Exterior Gateway Protocol

17

UDP

User Datagram Protocol

29

ISO-TP4

ISO Transport Protocol Clase 4

38

IDRP-CMTP

IDRP Control Message Transport Protocol

80

ISO-IP

ISO Internet Protocol (CLNP)

88

IGRP

Internet Gateway Routing Protocol (Cisco)

89

OSPF

Open Shortest Path First

255

Reservado

valor determinado de MTU y en su camino hacia el host de destino ha de pasar por otra red con una MTU menor. En estos casos, el router que hace la transici´on a la red de MTU menor ha de fragmentar los paquetes para que no excedan el tama˜ no de la nueva red. La segunda, llamada fragmentaci´ on en origen, se produce como consecuencia del dise˜ no de la aplicaci´on. Por ejemplo, muchas implementaciones del sistema de archivos de red NFS, que bastante usado en m´aquinas Unix, generan paquetes de 8 KBytes de datos (8212 bytes con el encabezado IP). Un host en una red Ethernet que utilice NFS tendr´a que fragmentar cada paquete en seis fragmentos antes de enviarlo, a´ un cuando el host de origen y destino se encuentren ambos en el mismo segmento Ethernet, debido al tama˜ no m´aximo que puede tener un frame Ethernet o IEEE 802.3. La fragmentaci´on se realiza cortando la parte de datos del paquete en trozos del tama˜ no m´aximo permitido por la nueva red. Todos los campos del encabezado del paquete original se repiten en los fragmentos, excepto aquellos que se emplean para distinguirlos entre s´ı. Una vez fragmentado, un paquete no se reensambla hasta que llegue al host de destino, a´ un cuando en el trayecto pase a trav´es de redes que admitan una MTU mayor. Los est´andares Internet 126

Tabla 9: Valor de MTU Para Protocolos Comunes de Nivel de Enlace. Protocolo a nivel de enlace MTU (bytes) PPP (valor por defecto)

1500

PPP (bajo retardo)

296

SLIP

1006 (l´ımite original)

X.25

1600 (RFC 1356)

Frame Relay

1600 (depende de la red)

SMDS

9235

Ethernet DIX

1500

Ethernet LLC-SNAP

1492

IEEE 802.4/802.2

8166

Token Ring 16 Mb/s

17940 (token holding time 8 ms)

Token Ring 4 Mb/s

4440 (token holding time 8 ms)

FDDI

4352

Hyperchannel

65535

Classical IP over ATM

9180

recomiendan que todas las redes que soporten TCP/IP tengan una MTU de al menos 576 bytes, condici´on que cumplen la mayor´ıa de las redes. La MTU m´ınima imprescindible para funcionar en TCP/IP es de 68 bytes, valor que corresponde a 60 bytes de encabezado (el m´aximo con todos los campos opcionales) y 8 bytes de datos, que es el fragmento m´ınimo de datos que puede hacerse. El campo identificaci´on del encabezado IP es usado por el emisor para marcar cada paquete emitido. De esta forma, en caso de que se produzca fragmentaci´on, el receptor podr´a reconocer las partes que corresponden al mismo paquete, ya que todas ir´an acompa˜ nadas de la misma identificaci´on. El bit DF cuando est´a en 1 indica a los routers que este paquete no debe fragmentarse, situaci´on que normalmente se hace por uno de los dos motivos siguientes: 1. El receptor no est´a capacitado para reensamblar los fragmentos. 2. Cuando se aplica la t´ecnica de descubrimiento de MTU del trayecto o “path MTU discovery” que permite averiguar el MTU de una ruta. Esta t´ecnica consiste en que el host de origen env´ıa un paquete del tama˜ no m´aximo al host de destino con el bit DF en 1. 127

Si el paquete no puede pasar en alg´ un punto del trayecto el router correspondiente genera un mensaje de error que es devuelto al host emisor. Entonces, ´este env´ıa otro paquete m´as peque˜ no, tambi´en con el bit DF en 1. As´ı, usando prueba y error, se consigue que alg´ un paquete pase sin fragmentar al host destino. Para acelerar el proceso, algunos routers incorporan en los mensajes de error informaci´on sobre la MTU m´aximo que puede admitir la red que ha provocado el rechazo. El campo Offset del Fragmento del paquete IP sirve para indicar, en el caso de que el paquete sea un fragmento, en que posici´on del original se sit´ uan los datos que contiene el fragmento actual. Las divisiones de un paquete siempre se realizan en m´ ultiplo de 8 bytes, que es la unidad elemental de fragmentaci´on, por lo que este campo cuenta los bytes en grupos de 8. Como los fragmentos de un paquete pueden llegar desordenados a su destino, el receptor podr´a identificarlos gracias al campo Identificaci´on. La longitud total del paquete puede calcularla cuando recibe el u ´ltimo fragmento, que est´a identificado por el bit MF en 0. A partir de los campos Longitud y Offset del Fragmento la longitud ser´a: F ragment Of f set ∗ 8 + Longitud. Cuando se fragmenta un paquete, el host receptor retiene en su buffer los fragmentos y los reensambla cuando los ha recibido todos. Mientras mantiene retenido un fragmento, el host va restando cada segundo una unidad al campo TTL. Cuando el valor de TTL es igual a cero, descarta el fragmento. Si alguno de los fragmentos de un paquete se pierde, el resto terminar´an desapareciendo a medida que agoten su TTL. En IP, no existe ning´ un mecanismo que contemple el reenv´ıo de paquetes o de fragmentos. Si el protocolo utilizado a nivel superior maneja reenv´ıo de datos perdidos, como es el caso de TCP a nivel de transporte, se provocar´a el reenv´ıo del paquete correspondiente. Normalmente, el segundo env´ıo se ver´a sometido a la misma fragmentaci´on que el primero, pero el segundo no podr´a en ning´ un caso aprovechar fragmentos residuales que pudiera haber en el host receptor correspondientes al primer env´ıo, ya que desde el punto de vista del nivel IP se trata de dos paquetes distintos e independientes que reciben identificaciones diferentes. 3.4.2.

Direcciones IP

Cada interfaz de red de cada host o router en una red IP se identifica mediante, al menos una, direcci´on u ´nica de 32 bits. Las direcciones IP se suelen representar por cuatro n´ umeros decimales separados por puntos, que equivalen al valor de cada uno de los cuatro bytes que componen la direcci´on. Por ejemplo, una direcci´on IP v´alida ser´ıa 152.74.21.3, que corresponde 128

al servidor web del Departamento de Ingenier´ıa El´ectrica de la Universidad de Concepci´on. Si un nodo dispone de varias interfases f´ısicas, como suele ser com´ unmente el caso de un router, cada una de ellas deber´a tener necesariamente una direcci´on IP distinta si se desea que sea accesible de forma diferenciada para este protocolo. Es posible tambi´en y en algunas situaciones resulta u ´til, definir varias direcciones IP asociadas a una misma interfaz f´ısica. Entre las diferencias que se pueden enumerar entre los dos tipos de direcciones conocidas hasta ahora (MAC e IP) est´an: 1. Las direcciones MAC son de 48 bits, separadas en 6 octetos y denotadas con n´ umeros hexadecimales. Las direcciones IP son de 32 bits, separadas en 4 octetos y denotadas con n´ umeros decimales. 2. Las direcciones MAC son direcciones de nivel de enlace, las direcciones IP son de nivel de red. 3. Las direcciones MAC est´an incluidas autom´aticamente en la interfaz, es decir, no es necesario especificar una direcci´on en particular, pues esta ya viene grabada en el firmware de la interfaz. Una direcci´on IP es una direcci´on que debe agregarse por software a un nodo, no viene almacenada en ´el, y esta direcci´on debe asignarse siguiendo criterios administrativos de la autoridad respectiva. 4. Las direcciones MAC no pueden cambiarse, pues est´an “incrustadas” en la interfaz de red (en realidad, s´ı pueden modificarse, pero en el 99 % de los casos no es necesario hacerlo). Las direcciones IP pueden cambiarse a voluntad, pues es un par´ametro agregado por software (nuevamente, si bien pueden cambiarse a voluntad, los cambios deben regirse por los criterios administrativos ya nombrados). 5. Las direcciones MAC no es necesario solicitarlas para poder usarlas. Las direcciones IP deben solicitarse a las entidades correspondientes, pues est´an asignadas por la IANA. Por ejemplo, la Universidad de Concepci´on dispone de la red 152.74.0.0 la cual debi´o ser solicitada y entregada a la Universidad por la IANA. Como corolario de las diferencias anteriores, se puede decir entonces que el agregar un nodo m´as a una red LAN es plug & play, pues no es necesario configurar una direcci´on de red, y en el caso de un computador, s´olo se necesitar´ıa configurar el hardware de red. En cambio, al usar el protocolo IP, es necesario especificar direcciones, lo que lleva a tener un grado mayor de conocimiento para la configuraci´on de un nodo, y la situaci´on no llega a ser plug & play 129

como en el caso anterior. Como se ver´a m´as adelante, es este grado de conocimiento el que permite una mejor organizaci´on y estructuraci´on de una red IP en comparaci´on con una LAN basada en MAC, producto de el orden l´ogico que puede establecerse con IP. Como ocurre en la mayor´ıa de las redes, las direcciones IP tienen una estructura jer´arquica. Una parte de la direcci´on es denominada direcci´on de red, y la otra direcci´on de host dentro de la red. Cuando un router recibe un paquete por alguna de sus interfases, compara la parte de red de la direcci´on con las entradas contenidas en sus tablas y reenv´ıa el paquete por la interfaz correspondiente, situaci´on denominada ruteo. 0

Red

1 0 1 1 0 1 1 1 1 1 1 1 1 0

A:1.0.0.0/127.255.255.255

Host Red

Host Red

B:128.0.0.0/191.255.255.255 Host

Dirección Multicast Reservado Para Uso futuro

C:192.0.0.0/223.255.255.255 D:224.0.0.0/239.255.255.255 E:240.0.0.0/247.255.255.255

32 bits

Figura 53: Formato de las Direcciones IP. En el dise˜ no inicial de Internet se reservaron los ocho primeros bits para la red, dejando los 24 restantes para el host, pues se cre´ıa que con 254 redes habr´ıa suficiente para la red experimental del DoD. Pronto se vio que esto resultaba insuficiente, por lo que se reorganiz´o el espacio de direcciones reservando rangos para definir redes m´as peque˜ nas. El resultado de esa reorganizaci´on es lo que hoy se conoce como redes clase A, B y C: Una red de clase A se caracteriza por tener en 0 el primer bit de direcci´on. El campo red ocupa, adem´as del primer bit que siempre est´a en 0, los 7 bits siguientes y el campo host los u ´ltimos 24. De aqu´ı se tiene que puede haber hasta 128 redes (7 bits para manejar) clase A, con 16777216 direcciones o nodos cada una (24 bits para manejar). Una red de clase B tiene el primer bit en 1 y el segundo en 0. El campo red ocupa, adem´as de los dos primeros bits que siempre est´an en 10, los 14 bits siguientes, y el campo host los 16 u ´ltimos. Puede haber entonces 16384 redes clase B (14 bits para manejar) con 65536 direcciones o cada una (16 bits para manejar). Una red clase C tiene los primeros tres bits en 110. El campo red ocupa, adem´as de los tres primeros bits que siempre est´an en 110, los siguientes 21 bits, y el campo host los 130

8u ´ltimos. Entonces, puede haber hasta 2097152 redes (21 bits para manejar) clase C con 256 direcciones cada una (8 bits para manejar). Para indicar qu´e parte de la direcci´on corresponde a la red y qu´e parte al host, se suele utilizar una notaci´on denominada m´ascara, que consiste en poner en 1 los bits que corresponden a la parte de red y a 0 los que corresponden a la parte host. As´ı por ejemplo, una red clase A tiene una m´ascara 255.0.0.0, lo que equivale a decir que los ocho primeros bits especifican la red y los 24 restantes el host. An´alogamente, una red clase B tiene una m´ascara 255.255.0.0 y una clase C una m´ascara 255.255.255.0. Las m´ascaras permiten extraer de forma sencilla la parte de red o de host de una direcci´on. Por ejemplo, un router que ha de enviar un paquete puede realizar un AND, bit a bit, entre la direcci´on de destino y la m´ascara correspondiente, con lo que extraer´a la parte de red de la direcci´on. Como segundo ejemplo, haciendo un NOT, bit a bit, a la m´ascara de red y usando este resultado para realizar una operaci´on OR, tambi´en bit a bit, con la direcci´on de alg´ un host, lo que se obtendr´a como resultado es la direcci´on de broadcast de la red. Esta direcci´on, como es de suponer, permite enviar un paquete IP a todos los nodos de la red, tal cual lo hace la direcci´on de broadcast de nivel de enlace. Existen adem´as de las clases A, B y C, direcciones clase D cuyos primeros cuatro bits est´an fijos en 1110. Las direcciones clase D se utilizan para definir grupos multicast. El grupo queda definido por los 28 bits siguientes, por lo que puede haber entonces hasta 268435456 direcciones multicast en Internet. Se debe hacer notar que una direcci´on clase D nunca puede aparecer como direcci´on de origen de un paquete. Finalmente, est´a la clase E, que corresponde al valor 1111 en los primeros cuatro bits, no se utiliza la clase por el momento y est´a reservada para usos futuros. De los valores de los primeros bits de cada una de las clases antes mencionadas se puede deducir el rango de direcciones que corresponde a cada una de ellas. As´ı pues, en la pr´actica es f´acil saber a que clase pertenece una direcci´on determinada sin m´as que observar el primer byte de su direcci´on. La Figura 53 muestra el esquema de direccionamiento IP. Existen algunas reglas y convenios que asignan significados especiales a determinadas direcciones IP: 1. La direcci´on 255.255.255.255 se utiliza para indicar broadcast en la propia red. Por ejemplo, podr´ıa se utilizada como direcci´on de destino por un host que est´a booteando desde la red en una LAN y, para averiguar la red en la que se encuentra, adem´as de su propia direcci´on IP, necesita localizar un servidor que le entregue los par´ametros de 131

configuraci´on b´asicos. Esta direcci´on s´olo se puede utilizar como direcci´on de destino, nunca como direcci´on de origen. 2. La direcci´on 0.0.0.0 identifica al host actual. En el caso anterior, la utilizar´ıa el host como direcci´on de origen de sus paquetes. S´olo se puede utilizar como direcci´on de origen, no de destino. 3. Las direcciones con el campo host en cero identifican redes y por tanto no se utilizan para ning´ un host. Se emplean para especificar rutas y nunca deber´ıan aparecer como direcciones de origen o destino de un paquete. Por ejemplo, la direcci´on 152.74.0.0 identifica la red clase B que pertenece a la Universidad de Concepci´on. 4. Una direcci´on con todos los bits del campo host en uno se utiliza como direcci´on de broadcast dentro de la red, por lo tanto, no se utiliza para ning´ un host y s´olo puede ser una direcci´on de destino. Por ejemplo, para enviar un mensaje broadcast a la red anterior se debe utilizar la direcci´on 152.74.255.255. 5. Una direcci´on con el campo red con todos los bits en cero identifica a un host en la propia red, cualquiera que sea la red. Por ejemplo, si se desea enviar un paquete al primer host (1.1) de una red clase B, se puede utilizar la direcci´on 0.0.1.1. Esto permite enviar un paquete a un host en una red sin saber el n´ umero de ´esta, aunque es preciso conocer si es clase A, B o C para saber que tama˜ no tiene la parte red de la direcci´on. 6. La direcci´on 127.0.0.1 se utiliza para pruebas de loopback. Todas las implementaciones de IP devuelven a la direcci´on de origen los paquetes enviados a esta direcci´on sin intentar enviarlos a ninguna parte. 7. Las redes 127.0.0.0, 128.0.0.0, 191.255.0.0, 192.0.0.0 y el rango de 240.0.0.0 en adelante (clase E) est´an reservados y no deben utilizarse. 8. Las redes 10.0.0.0 (1 red clase A), 172.16.0.0 a 172.31.0.0 (16 redes clase B) y 192.168.0.0 a 192.168.255.0 (256 redes clase C) est´an reservadas para redes privadas o intranets por el RFC 1918. Estos n´ umeros no se asignan a ninguna direcci´on IP v´alida en Internet. Por lo tanto, pueden utilizarse para construir redes, por ejemplo, detr´as de un firewall, o para usar como direcciones IP cuando no se dispone de ellas, sin riesgo de entrar en conflicto (repetir una direcci´on o direcciones IP) con redes v´alidas de la Internet.

132

Como consecuencia de las reglas 3 y 4 antes mencionadas siempre hay dos direcciones in´ utiles en una red, la primera y la u ´ltima. Por ejemplo, en la red 152.74.0.0 (clase B) se tiene que reservar la direcci´on 152.74.0.0 para denotar la red, y la direcci´on 152.74.255.255 para env´ıos broadcast a toda la red. Por lo tanto, se dispone de 65534 direcciones para hosts, no de 65356. La Figura 54 muestra un paquete IP real de tama˜ no 53 bytes, capturado con un sniffer. Este paquete, nuevamente corresponde a una parte de una sesi´on de lectura de correo electr´onico, entre m´aquinas de distintas subredes l´ogicas. En este caso, los rect´angulos de la parte inferior muestran las direcciones IP origen 152.74.22.11 (0x98.4A.16.0B) y destino 152.74.21.3 (0x98.4A.16.0B). El rect´angulo superior muestra otros par´ametros, como el TTL, largo total, protocolo encapsulado, etc.

Figura 54: Paquete IP Real.

3.4.3.

Divisi´ on en Subredes

Suponiendo que una empresa dispone de varias oficinas, cada una con una LAN, todas ellas interconectadas entre s´ı, y que desea unirlas mediante el protocolo TCP/IP y una de las oficinas dispone adem´as de una conexi´on a Internet y suponiendo tambi´en que cada oficina tiene suficiente con 254 direcciones de hosts. Entonces, en principio ser´ıa posible asignar una red clase C diferente para cada oficina, pero esto supone solicitar a IANA una red para cada 133

oficina que se conecte, y al ser cada una independiente de las dem´as la administraci´on se complica. Por ejemplo, es necesario anunciar en Internet la ruta para cada nueva red para que la oficina correspondiente fuera accesible. Dado que cada red ser´ıa, en principio, independiente de las dem´as no habr´ıa una forma sencilla de agrupar las redes de la organizaci´on. Una soluci´on alternativa ser´ıa solicitar una red clase A o una clase B, pero ¿c´omo organizar o dividir l´ogicamente la red para poder obtener una divisi´on por oficina y que no todas las oficinas caigan dentro de la misma red?. Existe un mecanismo que permite dividir una red IP en trozos o subredes, de forma que esta empresa podr´ıa solicitar una clase B y asignar fragmentos de dicha red a cada oficina a medida que se fueran incorporando a la red. Esto equivale a crear un nivel jer´arquico intermedio entre la red y el host, permitiendo as´ı grados variables de agrupaci´on seg´ un el nivel en que se encuentre. Suponiendo que a la empresa se le asigna una red clase B, la 152.74.0.0. De los 16 bits que en principio corresponden al host podr´ıa reservar los primeros 8 para subred y dejar los 8 siguientes para host, con lo que dispondr´a de 256 subredes de 256 direcciones cada una. Desde fuera, la red de la empresa seguir´a siendo 152.74.0.0, ya que la estructura de subred no ser´a visible. Para dividir la red en subredes se define una nueva m´ascara. Como siempre los bits en 1 de la m´ascara identifican la parte de red, en este caso, la parte de red y subred, y los bits en cero corresponden al host. Por ejemplo, la m´ascara 255.255.255.0 aplicada sobre una red clase B la divide en 256 subredes de 256 direcciones cada una, pues tiene puestos en 1 los primeros 24 bits. En cierto modo, se puede decir que esta m´ascara convierte una red clase B en 256 subredes clase C. Tambi´en se pueden hacer divisiones que no correspondan a bytes enteros. Por ejemplo, la m´ascara 255.255.252.0 hace subredes m´as grandes que las creadas en el caso anterior, reservando los primeros 6 bits para la subred y dejando 10 para el host, con lo que podr´ıa haber hasta 64 redes con 1024 direcciones cada una. Cuando se crean subredes hay dos direcciones en cada subred que quedan autom´aticamente ´ reservadas: las que corresponden al campo host todos en cero y todo en uno. Estas se emplean para designar la subred y para el broadcast dentro de la subred respectivamente. As´ı, si la red 152.74.0.0 se subdivide con la m´ascara 255.255.255.0 se crean 256 subredes del tipo 152.74.subred.host, cada una con 256 direcciones. En cada subred existen 254 direcciones aprovechables para hosts, ya que la primera direcci´on (152.74.subred.0) identifica a la subred y la u ´ltima (152.74.subred.255) es la direcci´on broadcast de esa subred. Del mismo modo que los valores de todos los bits en cero o en uno del campo host est´an 134

reservados con un significado especial, los valores de los bits todos en cero y todo en uno del campo subred tambi´en son especiales. El valor todos cero se utiliza para representar la subred misma. Por ejemplo, si a la red 152.74.0.0 se le aplica la m´ascara 255.255.255.0 la primera subred (campo subred todo a ceros) no deber´ıa utilizarse, pues resultar´ıa ambiguo el significado de la direcci´on 152.74.0.0, que representar´ıa tanto a dicha subred como a la red entera. An´alogamente, la u ´ltima subred (campo de subred todos en uno) tampoco deber´ıa utilizarse porque entonces la direcci´on 152.74.255.255 significar´ıa tanto broadcast en dicha subred como en la red entera. Mientras que la restricci´on de las direcciones todos los bits en cero o todos en uno en el campo host se ha de respetar siempre, existen muchas situaciones en las que interesa aprovechar la subred todos en cero o todos en uno, violando la norma antes mencionada. Esta violaci´on, permitida por muchas implementaciones, se conoce como subnet-zero y se adopta para aprovechar mejor el espacio de direcciones disponible. Con subnet-zero es posible, por ejemplo, dividir una red clase B por la mitad en dos subredes mediante la m´ascara 255.255.128.0, cosa que no ser´ıa posible si no se permitiera esta excepci´on a la regla. La Tabla 10 resume todas las posibles subredes y m´ascaras que se pueden utilizar con una red clase B, y la Tabla 11 cubre el caso de una red clase C. La divisi´on en subredes no necesariamente debe hacerse de forma homog´enea en todo el espacio de direcciones, como se ha hecho hasta ahora. Por ejemplo, podr´ıa partirse la red 152.74.0.0 en subredes de diferentes tama˜ nos y asignar a cada oficina una subred adecuada a sus necesidades. As´ı, en el ejemplo anterior se podr´ıa dividir la red 152.74.0.0 de la siguiente manera: 16 subredes de 256 direcciones (subredes desde 152.74.0.0 a 156.74.15.0 con m´ascara 255.255.255.0), 16 subredes de 1024 direcciones (subredes desde 152.74.16.0 a 156.74.76.0 con m´ascara 255.255.252.0), 3 subredes de 4096 direcciones (subredes desde 152.74.80.0 a 156.74.112.0 con m´ascara 255.255.240.0) y una subred de 32768 direcciones (subred desde 152.74.128.0 con m´ascara 255.255.128.0). La t´ecnica anterior que permite dividir una red en subredes de diferentes tama˜ nos se conoce como m´ ascaras de tama˜ no variable. 3.4.4.

Classless Inter-Domain Routing: CIDR

¿Qu´e hacer cuando las direcciones IP asignables est´an a punto de agotarse y la siguiente versi´on del est´andar simplemente no puede desplegarse a tiempo?. Soluci´on parche: recuperar los millones ya asignadas pero que nunca se usar´an. CIDR (RFCs 1466, 1518 y 1519) ha mantenido el crecimiento de Internet, reorganizando las direcciones IP de las cinco clases originales en un sistema sin clases. Antes de CIDR, 135

Tabla 10: Subredes y M´ascaras que Pueden Definirse en una Red Clase B. Bits subred

No de subredes

No subredes (subred cero)

Bits host

No hosts

M´ascara

0

0

0

16

65534

255.255.0.0

1

0

2

15

32766

255.255.128.0

2

2

4

14

16382

255.255.192.0

3

6

8

13

8190

255.255.224.0

4

14

16

12

4094

255.255.240.0

5

30

32

11

2046

255.255.248.0

6

62

64

10

1022

255.255.252.0

7

126

128

9

510

255.255.254.0

8

254

256

8

254

255.255.255.0

9

510

512

7

126

255.255.255.128

10

1022

1024

6

62

255.255.255.192

11

2046

2048

5

30

255.255.255.224

12

4094

4096

4

14

255.255.255.240

13

8190

8192

3

6

255.255.255.248

14

16382

16384

2

2

255.255.255.252

15

32766

32768

1

0

255.255.255.254

16

65534

65536

0

0

255.255.255.255

las direcciones IP se asignaban de acuerdo con el n´ umero de direcciones de “host” que una compa˜ n´ıa u organizaci´on necesitaba. Tres de las cinco clases (A, B y C) proporcionaron m´as de 3 mil millones de hosts utilizables en m´as de 2 millones de redes, mientras que las restantes eran para multicasting y uso experimental. Sin embargo, a principios de los a˜ nos 90, esas 2 millones de redes eran devoradas por los ISP que proporcionaban acceso a sus clientes y por compa˜ n´ıas que quer´ıan conectarse a internet por cuenta propia. Todas las direcciones clase A se hab´ıan agotado, y las de clase B s´olo se asignaban si se comprobaba su necesidad. Las de Clase C se asignaban a diario, acab´andose con tal rapidez que se tem´ıa se agotaran en cuesti´on de meses. Por otro lado, el problema no era s´olo la creciente necesidad de direcciones IP, sino que ya se hab´ıan asignado y no se utilizaban. Hab´ıa 125 redes clase A, y todas se subutilizaban. Por ejemplo, America Online era la u ´nica compa˜ n´ıa del planeta que pod´ıa necesitar tal n´ umero de direcciones, y s´olo si todos sus usuarios estuvieran en l´ınea al mismo 136

Tabla 11: Subredes y M´ascaras que Pueden Definirse en una Red Clase C. Bits subred

No de subredes

No subredes (subred cero)

Bits host

No hosts

M´ascara

0

0

0

8

254

255.255.255.0

1

0

2

7

126

255.255.255.128

2

2

4

6

62

255.255.255.192

3

6

8

5

30

255.255.255.224

4

14

16

4

14

255.255.255.240

5

30

32

3

6

255.255.255.248

6

62

64

2

2

255.255.255.252

7

126

128

1

0

255.255.255.254

8

254

256

0

0

255.255.255.255

tiempo. Con tantas direcciones en manos de tan pocas organizaciones, era preciso hacer algo para liberar algunas y usarlas de modo m´as eficaz. CIDR utiliza las mismas m´ascaras de direcci´on que se emplean en la divisi´on en subredes para crear grupos de direcciones clase C, permitiendo la recuperaci´on de porciones sustanciales de las antiguas redes clase A y B, con lo que se podr´ıan formar m´as de 10 millones de redes clase C. La desventaja de esta reagrupaci´on es el mayor tama˜ no de las tablas de ruteo centrales debido al mayor n´ umero de redes que necesitan que se les identifiquen rutas. Adem´as de esto, el tama˜ no de las tablas de ruteo se debe al mecanismo de asignaci´on de direcciones que se ha seguido, que ha sido estrictamente cronol´ogico y no existe correspondencia entre la ubicaci´on geogr´afica de una organizaci´on o del ISP y su rango de direcciones, por lo que no es posible resumir las tablas de rutas. Por esto, la informaci´on se ha de incluir enumerando una a una todas las redes existentes. Si se siguiera una organizaci´on jer´arquica de direcciones de acuerdo con criterios geogr´aficos, como ocurre en el direccionamiento de la red telef´onica, podr´ıa resolverse el problema. CIDR resuelve estos problemas de dos formas. La primera consiste en establecer una jerarqu´ıa en la asignaci´on de direcciones, que en vez de utilizar un criterio puramente cronol´ogico, que desde el punto de vista geogr´afico o de topolog´ıa de la red equivale a una asignaci´on aleatoria, los rangos se asignan por continentes. Inicialmente, se ha realizado el reparto de una parte del rango de redes clase C de la manera mostrada en la tabla 12. Con esta distribuci´on es posible agrupar las entradas en las tablas de ruteo en forma 137

Tabla 12: Agrupaci´on de Redes Clase C en Superredes Asignadas Geogr´aficamente. Multi regional 192.0.0.0 - 193.255.255.255 Europa

194.0.0.0 - 195.255.255.255

Otros

196.0.0.0 - 197.255.255.255

Noteam´erica

198.0.0.0 - 199.255.255.255

Centro y Sudam´erica

200.0.0.0 - 201.255.255.255

Anillo Pac´ıfico

202.0.0.0 - 203.255.255.255

Otros

204.0.0.0 - 205.255.255.255

Otros

206.0.0.0 - 207.255.255.255

geogr´afica. Por ejemplo, un router en Chile puede tener una sola entrada en su tabla indicando que todos los paquetes dirigidos a las redes 194.0.0.0 hasta 195.255.0.0 se env´ıen a la interfaz por la cual accede a Europa, evitando as´ı las 131072 entradas que normalmente har´ıan falta para este rango de direcciones. Sin embargo, este peque˜ no “arreglo” no es gratis, pues para que las rutas agrupadas sean posibles de rutear, es necesario modificar el software de los routers, ya que en principio no considera el rango 194.0.0.0-195.255.0.0 como una sola red sino como 131072 redes distintas. Por esto, se ha extendido el concepto de subred en sentido contrario, es decir la m´ascara no solo puede crecer hacia la derecha para dividir una red en subredes, sino que puede crecer hacia la izquierda para agrupar varias redes en una mayor, de ah´ı que a CIDR se le denomine tambi´en supernetting. Es decir, la parte de red de la direcci´on vendr´a especificada por la longitud de la m´ascara u ´nicamente, y la clasificaci´on tradicional en clases no tiene ning´ un significado, s´olo respet´andose dicho significado en el caso de las clases D y E. La segunda forma de solucionar el problema original, es una consecuencia de lo anterior, consiste en dar a cada organizaci´on la posibilidad de solicitar un rango de direcciones, pero que se ajuste a sus necesidades, d´andole siempre un rango contiguo y que tenga una m´ascara de red com´ un. Por ejemplo, si una empresa requiere una cantidad de 2048 direcciones IP, puede asign´arsele un grupo de ocho redes clase C consecutivas comenzando en 234.170.168.0 y terminando en 234.170.175.255. Con esto, su direcci´on de red CIDR ser´a 234.170.168.0 y su m´ascara 255.255.248.0. Recordar que la m´ascara por defecto de cada red clase C es 255.255.255.0, de aqu´ı se observa que la m´ascara se ha corrido hacia la izquierda, perdiendo tres bits. Se debe recordar tambi´en que esta reorganizaci´on permite transformar una tabla de ruteo que tendr´a 8 entradas para llegar al mismo punto en una que tendr´a s´olo una. 138

3.4.5.

Protocolos de Control IP

Normalmente, los paquetes IP transportan TPDUs (Transport Protocol Data Unit) o segmentos TCP o UDP, que son los dos protocolos de transporte utilizados en TCP/IP. Sin embargo, existen otros posibles contenidos para un paquete IP, en el que los datos que pueden transportarse son mensajes de los distintos protocolos de control de IP. ICMP (Internet Control Message Protocol) En las redes pueden producirse problemas, por lo tanto, deben generarse mecanismos que permitan devolver un mensaje al host emisor indic´andole lo sucedido. El mecanismo para reportar problemas en IP es el protocolo ICMP especificado en el RFC 792. Los mensajes ICMP viajan por la red como paquetes IP, con el valor 1 en el campo protocolo, y est´an sujetos a las mismas reglas que cualquier otro paquete al llegar a un router. Los mensajes ICMP son generados por el host o router que detecta el problema o situaci´on extraordinaria y son dirigidos al host o router que aparece en como direcci´on origen del paquete que caus´o el problema. Para facilitar la identificaci´on del paquete por parte del host emisor la mayor´ıa de los mensajes ICMP incluyen, adem´as del c´odigo de error correspondiente, el encabezado y los primeros ocho bytes de datos del paquete original. Los mensajes ICMP m´as importantes son: Destination Unreachable. Se produce cuando no se puede entregar el paquete a su destino, las causas que pueden generar un mensaje de este tipo son: cuando un router se encuentra con un paquete que tiene un 1 el bit DF y que no cabe en la MTU de la red por la que ha de enviarlo, o bien cuando un router no encuentra en sus tablas ninguna ruta por la que pueda llegar a la direcci´on para la que va dirigido el paquete. Cuando un router tiene configurada ruta por defecto, nunca enviar´a mensajes Destination Unreachable. Source Quench. Este mensaje se cre´o para permitir a los routers solicitar una reducci´on en el tr´afico generado por los hosts en caso de congesti´on. En la pr´actica, se ha observado que el uso de este tipo de mensajes agrava los problemas en caso de congesti´on, por lo que la recomendaci´on actual es que los routers no deben generar paquetes Source Quench en ning´ un caso. Echo Request & Echo Reply. Permiten detectar si un destino determinado est´a operativo. Al recibir el mensaje Echo Request el destino debe responder con un Echo Reply. El programa ping utiliza estos mensajes para su funcionamiento. 139

Time Exceeded. Este mensaje se env´ıa al emisor cuando un paquete es descartado porque su TTL ha llegado a cero, lo que puede ser s´ıntoma de que se ha producido alg´ un loop en la red o que el valor del TTL utilizado es demasiado bajo para el di´ametro de la red. El programa traceroute, que permite averiguar la ruta a un destino determinado, utiliza paquetes con TTL de 1, 2, 3, y as´ı sucesivamente, y a partir de los mensajes Time Exceeded recibidos puede deducir la ruta completa hasta el destino especificado. Redirect. Utilizado para alertar al host emisor cuando se sospecha que un paquete se est´a ruteando incorrectamente. Este mensaje lo utilizan los routers cuando reciben paquetes de un host que van dirigidos a otro host que se encuentra en la misma LAN. Resoluci´ on de Direcciones: ARP Cuando utiliza una red multiacceso, como por ejemplo una LAN, ATM, etc. , la tecnolog´ıa utilizada para enviar los paquetes de datos permite llegar por una misma interfaz f´ısica a m´as de un destinatario. En este caso, es necesario alg´ un mecanismo que permita saber a cual de todos los destinos posibles se dirigen los paquetes. Todas las redes multiacceso disponen de un sistema de direccionamiento propio, en el caso de una LAN las direcciones MAC de las estaciones son el m´etodo de direccionamiento. En todos estos casos, el nivel de red es el encargado de realizar el mapeo entre la direcci´on de la tecnolog´ıa multiacceso correspondiente y la direcci´on de red, situaci´on que se conoce como resoluci´ on de direcciones. Entre los m´ ultiples mecanismos de resoluci´on de direcciones se cuentan: 1. Por medio de una tabla est´atica, que es mantenida manualmente en cada nodo y que contiene la equivalencia completa de todas las direcciones. El principal problema que tiene es la necesidad de actualizar las tablas en todos los nodos de la red cada vez que se produce alguna modificaci´on en la tabla de direcciones. 2. Por medio de una tabla din´amica mantenida de forma autom´atica en un servidor que es conocido por todos los hosts. Cuando un nodo quiere enviar un mensaje a un destino determinado indica al servidor la direcci´on de red que busca y ´este le devuelve la direcci´on correspondiente. Debe existir un proceso de registro en el servidor para que un nodo pueda adherirse a la red. Los principales problemas de esta soluci´on son la necesidad del registro previo y que el servidor se convierte en un cuello de botella de la red, lo que puede llegar a limitar la confiabilidad y el desempe˜ no. 3. Establecer un mecanismo previamente conocido por el que se pueda deducir la direcci´on de la red multiacceso, a partir de la direcci´on de red. De esta forma, cualquier nodo 140

puede deducir la direcci´on de nivel dos, a partir de la direcci´on de red. Este mecanismo se emplea en DECNET que construye la direcci´on MAC a˜ nadiendo a la direcci´on de red un prefijo determinado y conocido por todos los nodos. 4. Utilizar un mensaje broadcast para lanzar a la red una pregunta solicitando la respuesta del nodo en la red multiacceso que posee la direcci´on de red buscada. Esta t´ecnica da m´axima flexibilidad ya que los equipos no necesitan registrarse y no hay un servidor centralizado del que dependa el funcionamiento de la red. Sin embargo, s´olo es factible de realizar en redes de naturaleza broadcast, como las redes locales. Su principal desventaja es el uso de paquetes broadcast que produce una degradaci´on del rendimiento de la red. Esta t´ecnica es la utilizada por IP sobre redes locales de todo tipo. El protocolo ARP funciona en base a esta u ´ltima alternativa, por ejemplo, si un nodo quiere iniciar conexi´on con otro host cuya direcci´on, a modo de simplificaci´on, se encuentra en la misma red local, entonces el emisor genera un mensaje ARP con la pregunta “¿qui´en tiene la direcci´on de red A.B.C.D?” y lo env´ıa como un frame Ethernet que tiene como direcci´on MAC destino la direcci´on de broadcast. El frame es recibido y procesado por todas los hosts activos, y eventualmente una m´aquina se reconoce propietaria de la direcci´on de red solicitada y responder´a entonces al mensaje. La respuesta puede ser, de hecho, normalmente lo ser´a, un frame unicast, puesto que el servidor ya conoce la direcci´on MAC del cliente que lanz´o la pregunta, y la respuesta incluir´a la direcci´on MAC solicitada, por lo que a partir de ese momento ambos hosts pueden comunicarse mediante frames unicast, reduciendo la generaci´on de tr´afico broadcast s´olo al primer mensaje. Para optimizar el proceso, cada nodo mantiene en memoria una tabla denominada cache ARP, con los pares de direcciones MAC-IP utilizadas recientemente. Generalmente, cuando un host env´ıa un ARP buscando a otro, todas los nodos, y no s´olo el destinatario del mensaje, aprovechan para captar al emisor, anot´andolo en su cache ARP, optimizando nuevamente el proceso. Las entradas de la tabla ARP expiran pasados unos minutos sin que haya tr´afico con la m´aquina correspondiente. A continuaci´on se presenta una tabla ARP en una m´aquina que utiliza Linux: lovecraft:~ # arp -a asimov.die.udec.cl (152.74.22.18) at 08:00:20:05:62:B2 [ether] on eth0 tolkien.die.udec.cl (152.74.22.19) at 08:00:20:05:44:31 [ether] on eth0 conan.die.udec.cl (152.74.22.13) at 08:00:20:1D:69:FB [ether] on eth0 jorgep.die.udec.cl (152.74.22.11) at 00:80:AD:C8:4E:6F [ether] on eth0 fwdali.die.udec.cl (152.74.22.1) at 08:00:20:73:44:51 [ether] on eth0 141

2 By

2 By

Tipo Hardware

Tipo Protocolo

1 By 1 By Long Dir Hw

Long Dir Prot

2 By Código Operación

Dir. MAC emisor

Dir. IP emisor

Dir. MAC destino

Dir. IP destino

6 By

4 By

Figura 55: Estructura de un paquete ARP IP para redes IEEE 802.

El formato del paquete ARP se observa en la Figura 55 y la descripci´on de los campos es la siguiente: Tipo de Hardware. 2 Bytes que especifican el tipo de red local. El c´odigo 1 identifica a Ethernet. Tipo de Protocolo. 2 Bytes que especifican el protocolo de red utilizado. Se emplean los mismos c´odigos que en el Ethertype. Longitud de Direcci´ on de Hardware: 1 Byte que determina el largo de la direcci´on de nivel 2, se especifica en bytes. Longitud de Direcci´ on de Red. 1 Byte que determina el largo de la direcci´on de red, se especifica en bytes. C´ odigo de Operaci´ on. 2 Bytes que valen 1 en el caso de una pregunta ARP y 2 en el de una respuesta. La Figura 56 muestra una petici´on ARP en un paquete real. En ella puede observarse la direcci´on IP y MAC del nodo fuente y la IP de la petici´on que se est´a haciendo. Tambi´en se observan otros valores como el tipo de hardware, protocolo de red, largos de direcciones, etc. Resoluci´ on Inversa de Direcciones A veces se plantea el problema inverso a ARP, es decir, encontrar la direcci´on IP a partir de una determinada direcci´on LAN. Por ejemplo, cuando se bootea un nodo sin disco ´este ha de cargar su sistema operativo desde otro host, que normalmente est´a situado en la misma red local, pero desconoce todo lo relativo a su configuraci´on de red, incluida la direcci´on IP. 142

Figura 56: Paquete ARP Real.

Lo u ´nico que la estaci´on conoce en principio es su direcci´on MAC, que se encuentra escrita en su tarjeta de red local. Para resolver esto existen las siguientes respuestas: RARP Reverse Address Resolution Protocol funciona de la siguiente manera: el nodo env´ıa un mensaje broadcast en el que indica su direcci´on MAC y solicita que alguien le informe cual es su direcci´on IP. En la red existe un servidor RARP encargado de atender este tipo de peticiones, que consultar´a sus tablas y devolver´a la direcci´on IP correspondiente. RARP utiliza el mismo formato de mensaje que ARP, la u ´nica diferencia es el uso de los c´odigos de operaci´on 3 y 4 para la pregunta y respuesta RARP, respectivamente. Como la consulta RARP se realiza mediante broadcast, el servidor RARP debe estar en la misma LAN que el cliente, ya que los mensajes broadcast a nivel MAC no atraviesan los routers. Otra limitaci´on de RARP es el hecho de que s´olo contiene el env´ıo de la direcci´on IP, y ser´ıa interesante aprovechar el mensaje para informar al cliente de todo el conjunto de par´ametros relacionados con la configuraci´on de la red: m´ascara, gateway, etc. BOOTP BOOTP (BOOTstrap Protocol) supera las limitaciones de RARP, ya que cuando un host lanza una pregunta BOOTP lo hace con un paquete IP con la direcci´on de destino 255.255.255.255 y direcci´on de origen 0.0.0.0. De esta forma, el paquete es recibido por todos los hosts de la LAN, y si alguno de ellos es el servidor BOOTP responder´a con los datos 143

requeridos en otro paquete broadcast IP (direcci´on 255.255.255.255). Si no existe ning´ un servidor BOOTP en la red local, deber´a existir alg´ un router designado como relay BOOTP que se encarga de retransmitir los mensajes BOOTP que reciba por una de sus interfases a trav´es de la cual pueda acceder al servidor BOOTP. De esta forma el servidor BOOTP puede colocarse en una ubicaci´on arbitrariamente remota respecto del cliente. Adem´as de la direcci´on IP, BOOTP permite indicar el nombre del host, la m´ascara de subred, el gateway, servidor de nombres, etc. DHCP RARP y BOOTP utilizan asignaci´on est´atica y u ´nica entre direcciones MAC y direcciones IP. Existen situaciones en las que esto no es conveniente. Por ejemplo, puede darse el caso de que se disponga de una sala para la conexi´on a Internet de hosts port´atiles, por lo tanto no se conocen las direcciones MAC de los clientes que se utilizar´an el servicio, y tampoco se sabe de antemano cuantos ser´an, lo u ´nico que se sabe es que no habr´a en ning´ un momento m´as nodos que la capacidad m´axima que posee la sala. El IETF, en 1993, dise˜ no el protocolo DHCP (Dynamic Host ConFiguration Protocol), que es similar a BOOTP pero es m´as vers´atil en los mecanismos de asignaci´on de direcciones IP. En DHCP los clientes pueden recibir sus direcciones por una de las siguientes formas: 1. Asignaci´on indefinida y est´atica. En este caso la direcci´on es fija y similar a BOOTP. 2. Asignaci´on autom´atica. La asignaci´on es tambi´en est´atica, pero la elecci´on de la direcci´on IP correspondiente es tomada por el servidor DHCP la primera vez que el equipo le solicita su direcci´on. 3. Asignaci´on din´amica. En este caso el cliente recibe la direcci´on IP del servidor durante un tiempo limitado. Pasado ese tiempo el cliente debe renovar su solicitud o de lo contrario la concesi´on expirar´a. De esta forma, una misma direcci´on puede ser reutilizada por diferentes m´aquinas en momentos diferentes. Las principales ventajas de DHCP son su mayor flexibilidad y la simplificaci´on de las labores de administraci´on. Un inconveniente de la asignaci´on din´amica de direcciones es que si se desea rastrear un problema y s´olo se dispone de la direcci´on IP, puede llegar a resultar imposible averiguar que nodo ha sido el causante del problema. Otro problema es la asociaci´on de direcciones y nombres en el DNS, pues con la asignaci´on din´amica diferentes m´aquinas pueden recibir el mismo nombre en diferentes momentos.

144

3.5.

Conceptos de Ruteo

Internet est´a formada por miles de redes interconectadas, pertenecientes a diversas empresas y organizaciones. Todas estas redes interconectadas comparten a nivel de red el protocolo IP. Al margen de esta interoperabilidad existen dos aspectos fundamentales en los que las redes pueden diferir entre si: El protocolo de routing utilizado: existe una gran variedad de protocolos de ruteo. A´ un utilizando el mismo algoritmo y protocolo de ruteo, dos proveedores diferentes normalmente no querr´an que sus routers intercambien entre s´ı la misma informaci´on de rutas que intercambian internamente. La pol´ıtica de intercambio de tr´afico: un proveedor puede tener acuerdos bilaterales o multilaterales para intercambiar tr´afico con otros, pero normalmente no estar´a dispuesto a ser utilizado como v´ıa de tr´ansito para el tr´afico entre dos proveedores si esto no est´a expresamente establecido en los acuerdos, a´ un cuando desde el punto de vista de topolog´ıa de la red pueda ser ese el camino m´as corto entre ambas. 3.5.1.

Sistema Aut´ onomo

Un sistema aut´onomo o AS ser´a la subred que es administrada por una autoridad com´ un, que tiene un protocolo de ruteo homog´eneo mediante el cual intercambia informaci´on en toda la subred y que posee una pol´ıtica com´ un para el intercambio de tr´afico con otras redes o sistemas aut´onomos. Normalmente cada ISP constituye su propio sistema aut´onomo, por ejemplo, REUNA 2 la red acad´emica a la cual est´a suscrita la Universidad de Concepci´on, corresponde a un sistema aut´onomo propio. As´ı pues, en Internet se dan, al menos, dos niveles jer´arquicos de ruteo, el que se realiza dentro de un sistema aut´onomo y el que se efect´ ua entre sistemas aut´onomos. El primero es denominado ruteo interno o intra´ areas, al segundo se le denomina ruteo externo o inter´areas. Dado que los requerimientos en uno y otro caso son muy diferentes, se utilizan protocolos de ruteo distintos. Los protocolos de ruteo interior se denominan IGP (Interior Gateway Protocol) y los utilizados entre sistemas aut´onomos se llaman EGP (Exterior Gateway Protocol). 3.5.2.

Protocolos de Ruteo Interior

Routing information Protocol (RIP) El protocolo m´as simple y antiguo es RIP, que viene provisto por el demonio routed en Unix, 145

y fue introducido en Berkeley para mantener tablas correctas en sus redes locales. Nunca fue concebido como un protocolo escalable de ruteo, a pesar que hoy se usa bastante en redes grandes. La idea es mantener en la tabla de ruteo, adem´as de la red y el gateway (que simplemente es ruta de salida por defecto), una m´etrica que cuente la distancia a la que se encuentra el host de esa red. De esta forma, al recibir otras posibles rutas a la misma red, puede elegir la m´as corta. RIP es un protocolo de vector de distancias, donde cada router puede verse como un nodo en un grafo, y las distancias son el n´ umero de nodos por los que debe pasar para llegar a su destino. Cada router maneja su tabla de ruteo, donde figuran todos los nodos del grafo y la distancia asociada (as´ı como el gateway). Cada cierto tiempo, los routers env´ıan esa tabla completa a todos sus vecinos. Al recibir la tabla de otro router, aprende los caminos a redes que no conoc´ıa (y los agrega a su tabla) y encuentra nuevos caminos a redes que ya conoc´ıa. Para elegir una ruta, compara las m´etricas (al recibir una tabla, le suma 1 a todas sus m´etricas, puesto que las redes est´an a un router m´as de distancia) y se queda con la m´as peque˜ na. En caso de igualdad, se queda con la ruta antigua, para evitar cambios permanentes en las rutas. Adem´as de las rutas aprendidas por RIP, t´ıpicamente se maneja una ruta default o gateway, y las rutas directas a las redes a las que est´a conectado el router, cuyas m´etricas son cero. Para encontrar a los dem´as routers y poder intercambiar con ellos las tablas, RIP utiliza un esquema de broadcast. Un router que habla RIP, difunde v´ıa broadcast a todas las redes a las que est´a conectado su tabla de rutas peri´odicamente. Al recibir un broadcast RIP, el router compara sus entradas con las recibidas y actualiza la tabla. Sin embargo, para poder adaptarse a fallas o ca´ıdas de routers, de debe poder realizar el borrado de rutas. Como no puede confiarse que el router ca´ıdo avise, se define un intervalo de tiempo fijo entre broadcasts, que en RIP por defecto es de 30 seg. Al transcurrir varios intervalos sin escuchar nada de un router (180 seg.) todas las rutas que fueron recibidas desde ´el se invalidan. RIP tiene varias ventajas, probablemente la principal es que funciona pr´acticamente s´olo, sin necesidad de configuraci´on o ingenier´ıa inicial. Basta habilitar RIP en el router, y ´este aprende y difunde todas las rutas autom´aticamente. Esta misma sencillez es su principal defecto, puesto que satura la red con broadcasts innecesarios y utiliza m´etricas que no toman en cuenta capacidades de las distintas redes. El principal problema de RIP es un defecto fundamental de cualquier protocolo de vector 146

de distancias: al manejar s´olo distancias, no puedo detectar los ciclos en las rutas. Al cambiar las rutas, es f´acil caer en ciclos infinitos. Para evitar el problema de los ciclos infinitos, en RIP se define que una m´etrica 16 es equivalente a infinito. Adem´as, se implementan otras soluciones (como split horizon que no difunde por una interfaz las rutas aprendidas por esa misma). Sin embargo, estas soluciones siempre tienen efectos laterales negativos. 1 By

1 By

2 By

Comando

Versión

0

AFI

0 Dirección 0 0 Métrica a)

Comando

Versión

No Usado

AFI

Etiqueta Ruta/Tipo Autentificación

Dirección/Autentificación Máscara de Subred/Autentificación Siguiente Salto/Autentificación Métrica/Autentificación b)

Figura 57: Estructura de un paquete a) RIP b) RIPv2.

La Figura 57a) ilustra el formato de un paquete RIP, la descripci´on de los campos es la siguiente: Comando. 1 Byte que indica si el paquete es una petici´on o respuesta. La petici´on es una solicitud a un router para que env´ıe toda o parte de su tabla, informaci´on que estar´a contenida en un paquete de respuesta. Versi´ on. 1 Byte especificando la versi´on del protocolo. Cero. dos campos de 2 Bytes y dos de 4 Bytes, no utilizados cuyo valor es cero. AFI. 2 Byte que especifica la familia de la direcci´on utilizada, lo que permite transportar diversos protocolos. Direcci´ on. 4 Bytes para la direcci´on de red de cada entrada de la tabla de ruteo. 147

M´ etrica. 4 Bytes que indican el n´ umero de saltos. Su valor puede ir entre 1 y 15. Existe un m´aximo de 25 ocurrencias para los AFI, Direcci´on y M´etrica en un u ´nico paquete RIP, lo que permite enviar hasta 25 destinos. Tablas de mayor volumen pueden enviarse usando varios paquetes. La Figura 57b) muestra el formato de un paquete RIPv2, que es una ampliaci´on al protocolo anterior y permite enviar una mayor cantidad de informaci´on. La descripci´on de los campos es la siguiente: Comando. 1 Byte que indica si el paquete es una petici´on o respuesta. La petici´on es una solicitud a un router para que env´ıe toda o parte de su tabla, informaci´on que estar´a contenida en un paquete de respuesta. Versi´ on. 1 Byte especificando la versi´on 2 del protocolo. No Usado. 2 Bytes no utilizados cuyo valor es cero. AFI. 2 Byte que especifica la familia de la direcci´on utilizada, lo que permite transportar diversos protocolos. Este campo presenta una peque˜ na diferencia con la versi´on anterior de RIP, si el valor es 0xFFFF, entonces el paquete enviado no contiene tablas, sino que es un paquete de autentificaci´on, por lo que el campo de 2 Bytes siguiente pasa a llamarse Tipo de Autentificaci´on y los 16 Bytes siguientes a ´este se llaman Autentificaci´on. Etiqueta de Ruta. 2 Bytes que permiten distinguir si las rutas son internas, es decir, aprendidas por RIP o externas, que son aquellas aprendidas desde otros protocolos. Tipo de Autentificaci´ on. En el caso de que el campo AFI indique que se trata de un paquete de autentificaci´on, el campo Etiqueta de Ruta toma este nombre. Actualmente, el tipo de autentificaci´on usado corresponde s´olo a un password en texto plano. Direcci´ on. 4 Bytes para direcci´on de red de cada entrada de la tabla de ruteo. M´ ascara de Subred. 4 Bytes que contienen la m´ascara de subred. En el caso de que el valor sea 0, entonces no se ha especificado una m´ascara. Siguiente Salto. 4 Bytes para indicar la direcci´on del siguiente salto al cual los paquetes deben ser reenviados. M´ etrica. 4 Bytes que indican el n´ umero de saltos. Su valor puede ir entre 1 y 15. 148

Autentificaci´ on. 16 Bytes que permiten ingresar un password, en texto plano, para la autentificaci´on. Este campo permite un m´aximo de 16 caracteres para el password, los cuales son rellenados con ceros hasta completar los 16 en caso de ser menor. Al igual que en el caso anterior, hasta 25 entradas pueden indicarse en un paquete IP.

Figura 58: Formato de un paquete RIP Real.

La Figura 58 muestra un paquete RIP real, en el rect´angulo rojo superior se observan las marcas de tiempo, si se observa que la actualizaci´on (Response) es emitida cada 30 seg. En el rect´angulo rojo del medio se puede ver la tabla completa de rutas que se est´a transmitiendo, mientras que en el pol´ıgono rojo inferior tiene marcada la primera entrada de la tabla en forma completa. La elipse en verde marca la red que se est´a exportando 152.74.20.0 (98.4A.14.0) y la flecha marca la m´etrica (1). A continuaci´on se presenta, como ejemplo, la situaci´on de hacer hablar a una m´aquina Linux RIP, usando el programa Zebra (http://www.zebra.org). Inicialmente se muestra la tabla de rutas del nodo usando el programa route, luego se activa zebra y rip y se vuelve a desplegar la tabla de rutas, donde en este caso la m´aquina ha aprendido las rutas que estaban circulando por la red. 149

lovecraft:/etc/zebra # route -n Kernel IP routing table Destination

Gateway

Genmask

Flags Metric Ref

Use Iface

152.74.22.0

*

255.255.255.0

U

0

0

0 eth0

loopback

*

255.0.0.0

U

0

0

0 lo

lovecraft:/etc/zebra # zebra -d lovecraft:/etc/zebra # ripd -d lovecraft:/etc/zebra # route -n Kernel IP routing table Destination

Gateway

Genmask

Flags Metric Ref

Use Iface

152.74.22.0

0.0.0.0

255.255.255.0

U

0

0

0 eth0

152.74.21.0

152.74.22.1

255.255.255.0

UG

2

0

0 eth0

152.74.20.0

152.74.22.1

255.255.255.0

UG

1

0

0 eth0

127.0.0.0

0.0.0.0

255.0.0.0

U

0

0

0 lo

Interior Gateway Routing Protocol (IGRP) Con la creaci´on de IGRP a principios de los ochentas, Cisco Systems fue la primera compa˜ n´ıa en resolver los problemas asociados con el uso de RIP para rutear paquetes entre routers interiores. IGRP determina la mejor ruta a trav´es de una red examinando el ancho de banda y la demora de las redes entre los routers. IGRP converge m´as r´apido que RIP, por lo tanto se evitan los ciclos de ruteo causados por el desacuerdo entre routers sobre cual es el pr´oximo salto a ser tomado. M´as a´ un, el IGRP no tiene limitaci´on en cuanto a contador de saltos. Por lo anterior, el IGRP es utilizado en redes de gran tama˜ no, complejas y con diversidad de topolog´ıas. IGRP utiliza una m´etrica compuesta que es calculada por una suma ponderada de los valores de retardo entre redes, ancho de banda del enlace, confiabilidad y carga, donde el administrador de la red puede dar valores arbitrarios para las ponderaciones, lo que permite un grado mayor de flexibilidad. Una caracter´ısticas adicional de IGRP es que permite ruteo multitrayectoria, lo que permite, por ejemplo, establecer l´ıneas de respaldo en caso de fallas. Para mejorar la estabilidad del algoritmo de vector de distancias, IGRP utiliza mensajes Holddown que evitan que las actualizaciones regulares enviadas por los routers comiencen el problema de la cuenta hasta infinito, ya que al detectar una falla, debido a la falta de actualizaciones, un router que detecte esto env´ıa el mensaje Holddown para evitar que comiencen las sucesivas actualizaciones y se genere la cuenta hasta infinito. este mensaje es un per´ıodo de 150

tiempo en el que no deben actualizarse las rutas recibidas. IGRP tambi´en utiliza las t´ecnicas Split Horizon y Poison-Reverse en el env´ıo de actualizaciones para prevenir loops informaci´on entre routers adyacentes. Finalmente, IGRP mantiene una serie de timers e intervalos de tiempo, entre los que se incluye un timer para actualizaciones o Updates (cuyo valor por defecto es 90 seg.), uno para marcar las rutas como no v´alidas (por defecto 3*Update=270 seg.), uno para el tiempo de Holddown (por defecto 3*Update+10=280 seg.) y uno para el de descarte de rutas (por defecto 7*Update=630 seg.). Enhanced Interior Gateway Routing Protocol (EIGRP) Cisco lanz´o tambi´en una nueva versi´on de IGRP para manipular redes de alto crecimiento y misi´on-cr´ıtica. Esta nueva versi´on es conocida como EIGRP (Enhanced IGRP) y combina la facilidad de uso de los protocolos de ruteo de vector de distancia tradicional con las capacidades de reruteo r´apido de los protocolos estado del enlace. El EIGRP consume mucho menos ancho de banda que el IGRP, porque ´este es capaz de limitar el intercambio de informaci´on de ruteo para incluir solamente la informaci´on que ha cambiado. Adem´as, es multiprotocolo pues capaz de manipular informaci´on de ruteo de AppleTalk, IPX e IP. Intermediate System-Intermediate System (IS-IS) El protocolo de ruteo IS-IS est´a basado en el algoritmo de estado de enlace. Adem´as IS-IS permite hacer routing integrado, es decir, calcular las rutas una vez y aplicarlas para todos los protocolos utilizados, permitiendo as´ı aut´entico routing multiprotocolo. Admite adem´as, hasta ocho niveles de jerarqu´ıa para reducir la cantidad de informaci´on de routing intercambiada. IS-IS fue dise˜ nado para el protocolo DECNET de Digital y adoptado despu´es por ISO como protocolo de routing para el protocolo de red CLNP. Una variante de IS-IS se utiliza en Netware de Novell. IS-IS no es un est´andar Internet, pero se utiliza en algunos sistemas aut´onomos. Open Shortest Path First (OSPF) OSPF es una alternativa m´as reciente a RIP entre los protocolos de routing internos, y que corrige todas las limitaciones que ten´ıa ´este. OSPF fue desarrollado por el IETF (Internet Engineering Task Force) como el reemplazo de RIP. Este protocolo es soportado por todos los principales vendedores de equipos de ruteo IP. OSPF es un protocolo de ruteo del tipo estado 151

de enlace, que soporta ruteo jer´arquico dentro de un sistema aut´onomo. OSPF provee una r´apida convergencia y soporta m´ascaras de subred de longitud variable. OSPF se deriv´o del protocolo de ruteo IS-IS de la OSI, y algunas de sus caracter´ısticas especiales incluyen ruteo de m´ ultiples trayectorias de costo y ruteo basado en un tipo de nivel superior de solicitudes del servicio (ToS Type of Services). Por ejemplo, una aplicaci´on puede especificar que ciertos datos son urgentes y si OSPF tiene enlaces de alta prioridad a su disposici´on, ellos pueden ser utilizados para transportar un paquete urgente. OSPF soporta uno o m´as m´etricas. En OSPF, un router no intercambia distancias con sus vecinos. En vez de eso, cada router chequea el status de cada uno de sus enlaces con los routers adyacentes y env´ıa a ´estos la informaci´on recogida, la que se propaga de esta forma a trav´es del sistema aut´onomo. Cada router captura esta informaci´on y construye su tabla de ruteo, y todos los routers involucrados tendr´an la misma tabla de ruteo. Desde un punto de vista pr´actico, la diferencia m´as importante es que un protocolo de estado del enlace converge con mayor rapidez que un protocolo de vector de distancia. Por convergencia se entiende que la estabilizaci´on despu´es de cambios en la red, como ca´ıdas de router o de enlaces. OSPF se diferencia de RIP (y de otros muchos protocolos de ruteo) en que utiliza s´olo IP, o sea, no es multiprotocolo. Adem´as de ser un protocolo de enlace en vez de distancia, OSPF tiene otras muchas caracter´ısticas que lo hacen superior a RIP: 1. OSPF puede calcular un conjunto separado de rutas para cada tipo de servicio IP. Esto quiere decir que para un mismo destino puede haber varias entradas en la tabla de ruteo, una por cada tipo de servicio. 2. A cada interfaz se le asigna un costo. Este puede asignarse en funci´on del ancho de banda de salida, seguridad, confiabilidad, etc. Pueden asignarse distintos costos para distintos servicios. 3. Cuando existen varias rutas a un mismo destino, con id´enticos costos, OSPF distribuye el tr´afico por ambas rutas de forma equitativa. 4. OSPF soporta subredes: una m´ascara de subred es asociada con cada ruta notificada. Esto permite que una u ´nica direcci´on IP de cualquier clase pueda ser dividida en m´ ultiples subredes de varios tama˜ nos. Las rutas a un host son notificadas mediante una m´ascara de subred con todos los bits a 1. Una ruta por defecto es notificada como una direcci´on IP de 0.0.0.0 con una m´ascara con todos los bits a 0. 152

5. Los enlaces punto a punto entre routers no necesitan una direcci´on IP a cada extremo, esto es lo que se conoce como redes no numeradas. De esta forma se ahorran direcciones IP. 6. Es posible emplear un peque˜ no mecanismo de autentificaci´on ya que es posible enviar un password de manera similar a como lo hacer RIPv2. 7. OSPF emplea multicast en vez de broadcast, para reducir la carga en los sistemas que no emplean OSPF. Si se considera que todos los routers poseen el mismo grafo representativo de la red, el protocolo se basa en el c´alculo del ´arbol de distancias m´ınimas desde un nodo determinado. El ´arbol resultante depender´a del nodo desde el cual se realice el c´alculo. Los enlaces que no est´an marcados se considera que tienen una distancia de 0. Una vez calculado el ´arbol, los paquetes se enviar´an por la rama m´as corta que conduzca al destino. A partir de ah´ı, ser´an los siguientes routers los que decidan la ruta a seguir. La actualizaci´on de la tabla se puede realizar mediante protocolos externos como BGP, o puede modificarse de forma est´atica. Tambi´en es posible a˜ nadir rutas por defecto. ´ Dominio de Ruteo OSPF y Areas. OSPF permite que se agrupen juntas colecciones de redes y hosts. Esta agrupaci´on, junto con todos los routers que tienen interfases a cualquiera de las redes incluidas es llamada un ´area. Cada ´area ejecuta una copia separada del algoritmo de ruteo b´asico SPF, lo que implica que cada ´area tiene su propia base de datos topol´ogica. La topolog´ıa de un ´area es invisible para cualquier dispositivo que no pertenezca a ella. Es decir, los router internos de un ´area espec´ıfica no saben nada de la topolog´ıa externa al ´area. Esta aislaci´on es la que permite introducir un bajo tr´afico de ruteo en la red, en comparaci´on a la idea de compartir toda la informaci´on del sistema aut´onomo. Los routers que est´an conectados a m´ ultiples ´areas son llamados routers de borde de ´area (ABR). Es as´ı como dos routers que pertenecen a una misma ´area tienen, para esa ´area, una base de datos id´entica. El ruteo en un sistema aut´onomo tiene dos niveles, dependiendo de si la fuente y el destino est´an en una misma ´area o no. El ruteo intra´ area pertenece al primer caso, los paquetes son ruteados con informaci´on exclusivamente del ´area en cuesti´on. Esto protege al ruteo de la inyecci´on de informaci´on corrupta. En el ruteo inter´area, se obtiene informaci´on del o las ´areas exteriores involucradas.

153

Backbone OSPF. Todo dominio de ruteo OSPF debe tener un backbone. El backbone es un ´area especial que tiene un identificador 0.0.0.0, o simplemente 0, y consiste en todas las redes que no son contenidas en ning´ un ´area espec´ıfica, sus routers asociados y los routers que pertenecen a m´ ultiples ´areas. El backbone tiene como restricci´on que debe ser contiguo, lo que lo hace ser el punto de convergencia de todas las ´areas del sistema aut´onomo. Cada una de las interfases que son configuradas en el ´area 0 deben ser alcanzables v´ıa otros routers, donde cada interfaz en la trayectoria est´a configurada como si estuviera en el ´area 0. A pesar de que el backbone debe ser contiguo, es posible definir ´areas en las que ya no lo sea, es decir, donde se rompa la continuidad entre routers. Esto es posible mediante la configuraci´on de enlaces virtuales. Backbone Router Router Router

ABR

Area 1

Routers Internos

FDDI

Area de Backbone

Router Router

Router

ABR

Router

Area 2

Routers Internos ABR Router de Borde AS

Sistema Autónomo Externo

Router

Router

Routers Internos

Area 3

Router

Figura 59: Descripci´on de los Tipos de Routers y Relaciones en OSPF.

Clasificaci´ on de los Routers OSPF. Cuando un sistema aut´onomo se divide en ´areas, los routers pueden clasificarse, de acuerdo a la funci´on que cumplen, en cuatro clases que se traslapan entre s´ı. 154

Router Interno. Tiene todas sus interfases conectadas a redes que pertenecen a la misma ´area. Los routers con interfases s´olo en el backbone tambi´en pertenecen a esta clase. Estos routers ejecutan una sola copia del algoritmo SPF. ´ Router de Borde de Area. Se unen a m´ ultiples ´areas, ejecutan m´ ultiples copias del algoritmo SPF, una por cada ´area a la que se asocian y una adicional para el backbone. Tienen la misi´on de condensar la informaci´on de sus ´areas para su distribuci´on por el backbone, que la distribuye a otras ´areas. Router de Backbone. Tiene al menos una interfaz conectada al backbone, por lo tanto, incluye tambi´en todos los routers que se asocian a m´as de un ´area, esto no implica necesariamente que sean routers de borde de ´area. Router de Borde de AS. Intercambia informaci´on de ruteo con otros routers pertenecientes a otros sistemas aut´onomos. La trayectoria hacia estos routers es conocida por cada uno de los routers del sistema aut´onomo. Esta clasificaci´on es totalmente independiente de las anteriores, un router de borde de AS pude ser interno o de borde de ´area, y puede o no participar en el backbone. La Figura (59) muestra varios tipos de routers OSPF y la relaci´on entre ellos y con todo el ambiente OSPF. Vecinos y Adyacencias. OSPF crea adyacencias entre routers vecinos para facilitar el intercambio de informaci´on. Los routers vecinos son dos routers que tienen interfases a una red en com´ un. En las redes multiacceso, los vecinos son descubiertos en forma din´amica, utilizando el protocolo de OSPF Hello. Una adyacencia es una relaci´on formada entre los routers vecinos seleccionados con el prop´osito de intercambiar informaci´on de ruteo. No todos los pares de routers vecinos llegan a ser adyacentes. En cambio, las adyacencias son establecidas con un subconjunto de los routers vecinos. Los routers que est´an conectados por enlaces punto-a-punto o mediante enlaces virtuales son siempre adyacentes. En las redes multiacceso, todos los routers llegan a ser adyacentes al router designado y al router designado de respaldo. Router Designado y Router Designado de Respaldo. Todas las redes multiacceso tiene un router designado y otro que servir´a de respaldo en caso de que el primero falle. Las dos funciones principales de este router son: 155

Originar los avisos de enlace de red de parte de la red. Este anuncio lista el conjunto de routers, incluyendo el designado, que actualmente est´an unidos a la red. Llegar a ser adyacente a todos los otros routers de la red. Debido a que las bases de datos de estado de enlace son sincronizadas a trav´es de adyacencias (a trav´es de la inicializaci´on de la adyacencia y de un proceso de inundaci´on), el router designado juega un papel principal en el proceso de sincronizaci´on. 1 By

1 By

2 By

Versión

Tipo

Largo del Paquete

Router ID CRC

Área ID Tipo de Autentificación Autentificación Autentificación Datos

Figura 60: Estructura de un paquete OSPF.

La Figura 57a) ilustra el formato de un paquete RIP, la descripci´on de los campos es la siguiente: Versi´ on. 1 Byte que identifica la versi´on del protocolo OSPF utilizada. Tipo. 1 Byte que identifica el tipo del paquete del OSPF como alguno de los siguientes: Hello (que establece y mantiene relaciones con los vecinos); descripci´ on de la base de datos (describe el contenido de la base de datos topol´ogica, estos mensajes se intercambian cuando se inicializa una adyacencia); petici´ on Link-Sate (solicita, a los routers vecinos, una actualizaci´on de alguna parte de la base de datos topol´ogica. Estos mensajes se intercambian despu´es de que un router descubre que esas partes de su base de datos topol´ogica no est´an actualizadas); actualizaci´on Link-State (es la respuesta a un paquete de petici´on o puede corresponder tambi´en a una actualizaci´on regular del protocolo de estado de enlace regular, actualizaciones llamadas LSAs); Link-Sate Acknowledge (paquete de confirmaci´on de las actualizaciones). Largo del Paquete. 2 Bytes que especifica la longitud del paquete, incluyendo el encabezado OSPF, el valor est´a medido en bytes. 156

Router ID. 4 Bytes que identifican el origen del paquete. ´ Area ID. 4 Bytes que identifican el ´area a la que pertenece el paquete. Todos los paquetes OSPF est´an asociados a una sola ´area. CRC. 2 Bytes para verificar el contenido total del paquete por si ha sufrido alg´ un da˜ no durante su tr´ansito. Tipo de Autentificaci´ on. 2 Bytes que contienen el tipo de autentificaci´on, ya que todo el intercambio de protocolos OSPF se autentifica. El tipo de autentificaci´on se configura en cada ´area. Autentificaci´ on. 8 Bytes que contienen la informaci´on de autentificaci´on. Datos. Valor variable que contiene informaci´on encapsulada de las capas superiores. La Figura 61 muestra un paquete OSPF real, en los rect´angulos rojo en la parte a) de la figura se observan las direcciones de red origen y destino. Notar que el destino es una direcci´on IP multicast (224.0.0.5) en vez de un broadcast de IP como es el caso de RIP. Esto hace que OSPF introduzca un menor tr´afico que RIP y que “moleste” menos las CPUs de los nodos presentes en la red que deber´an procesar siempre cualquier paquete broadcast que reciban. En la Figura 61a) tambi´en se observa la versi´on del protocolo utilizada y el tipo de paquete que se est´a analizando, en este caso un LSA o actualizaci´on de rutas. En al parte b) se observa la marca de tiempo que tiene el LSA, el n´ umero de secuencia y otros datos. La informaci´on relevante aparece marcada en el rect´angulo rojo y corresponde a una de las redes (152.74.21.0/24) y su m´etrica (1), informaci´on que est´a siendo enviada en el paquete de actualizaci´on. 3.5.3.

Protocolos de Ruteo Exterior

Protocolo de Gateway Exterior (EGP) La autoridad administrativa asociada con cada sistema aut´onomo nomina uno o m´as routers para funcionar como router exterior para esos sistemas. Dentro de los AS, ´estos se comunican con otros routers interiores usando el IGP acordado para ese sistema. De ah´ı en adelante, cada router exterior, mediante su tabla de ruteo local, sabe sobre los net IDs dentro de ese sistema y sus distancias desde ese router. Cuando cada router exterior es inicializado, en primer lugar, se da la identidad u ´nica del sistema aut´onomo a la cual se accesar´a. Tambi´en recibe el contenido de una tabla de ruta, conocida como la tabla de capacidad, que le permite 157

a)

b)

Figura 61: Formato de un paquete OSPF Real.

comunicar con todos los otros gateways exteriores. El protocolo de gateway exterior (EGP) tambi´en envuelve cada gateway o router exterior haciendo contacto con nodos exteriores seleccionados, no con todos ni con cualquier router externo al azar, e intercambia informaci´on 158

de ruteo con ellos. Esta informaci´on de ruta consiste de la lista de net IDs dentro del sistema aut´onomo correspondiente, junto con sus distancias y routers desde el gateway exterior. La u ´ltima es usada para enviar un router y seleccionar el mejor gateway exterior para ser usado cuando se env´ıan paquetes a un sistema aut´onomo particular. Las tres funciones principales asociadas con el EGP son: Adquisici´on vecina. Disponibilidad vecina. Actualizaci´on de ruta. Cada funci´on opera usando un mensaje solicitud-respuesta. En cada sistema aut´onomo se administra y corren los protocolos por una autoridad diferente, por lo que antes de que cualquier informaci´on de ruteo sea cambiada, dos routers exteriores asociados a sistemas diferentes deben primero ponerse de acuerdo para poder intercambiar informaci´on. Este es el rol del procedimiento de adquisici´on vecina (neighbour acquisition), y cuando dos routers acuerdan un intercambio, ellos se dicen vecinos. Cuando se termina el intercambio, se ejecuta un protocolo de terminaci´on vecina que finaliza el traspaso de informaci´on. Cuando un router primero puede cambiar informaci´on de ruteo, es enviado un mensaje de pedido de adquisici´on hacia el EGP en el router del otro AS, que es el encargado de devolver otro mensaje que confirma la adquisici´on o, si esto no se puede aceptar, la respuesta es un mensaje que rehusa la adquisici´on, donde se incluye un c´odigo de error. Una vez que una relaci´on de vecino ha sido establecida entre dos routers, y por lo tanto, entre dos AS, ellos peri´odicamente confirman su relaci´on usando el protocolo de disponibilidad vecina. Este no est´a hecho para cambios espec´ıficos de mensajes o para agregar informaci´on de confirmaci´on dentro del encabezado de mensajes de informaci´on de ruta normal, sino para confirmar que mantienen la relaci´on de confianza entre ellos para poder intercambiar rutas. El intercambio de informaci´on de ruta es llevado fuera por uno de los routers enviando un mensaje de solicitud de espera hacia el otro router pregunt´andole por la lista de redes (Net IDs) que son capaces de alcanzarse v´ıa ese router y otros distantes de ´el. La respuesta es un mensaje de actualizaci´on de ruta que contiene la informaci´on requerida. Finalmente, si cualquier mensaje requerido es incorrecto, un mensaje de error es retornado como respuesta con un apropiado c´odigo de error. Al igual que con los otros protocolos IP, todos los mensajes asociados con el EGP son llevados en el campo de datos de usuario de un paquete IP. Todo mensaje EGP tiene el 159

1 By

1 By

1 By

1 By

Versión

Tipo

Código

Status

CRC

AS ID

Número Secuencia

Routers Int Dirección

Routers Ext

i-ésimo Siguiente Salto Nº Dist Dist j-ésima

Nº Redes Red k-ésima a Dist j

Figura 62: Estructura de un paquete de actualizaci´on EGP.

mismo encabezado fijo, que es el mostrado en los primeros 10 bytes del paquete de la Figura 62 para el caso de un mensaje de actualizaci´on. El detalle de campos, para este caso, se describe a continuaci´on: Versi´ on. 1 Byte que define el n´ umero de versi´on del protocolo EGP. Tipo. 1 Byte define el tipo de mensaje enviado: adquisici´on de vecino, disponibilidad, actualizaci´on, etc. C´ odigo. 1 Byte que corresponde a una extensi´on del campo Tipo y funciona definiendo un subtipo para el mensaje. Por ejemplo, una solicitud de vecino podr´ıa ser una petici´on, respuesta, rechazo, etc. Status. 1 Byte contiene informaci´on sobre la condici´on en que se encuentra el mensaje, y es dependiente del tipo de mensaje. CRC. 2 Bytes de checksum usado como un sistema de correcci´on de errores. AS ID. son 2 Bytes que corresponden al n´ umero sistema de AS asignado a la red a la que el router remitente pertenece. N´ umero de Secuencia. 2 Bytes usados para dar respuestas sincronizadas para los mensajes de pedido correspondientes utilizando numeraci´on de paquetes. Routers Internos. 1 Byte que corresponde al n´ umero de routers interiores al AS que aparecen en el mensaje.

160

Routers Externos. 1 Byte que corresponde al n´ umero de routers exteriores al AS que aparecen en el mensaje. Direcci´ on. 4 Bytes para especificar la direcci´on de red desde la que se entrega la informaci´on de accesibilidad. i-´ esimo Siguiente Salto. 1 a 3 Bytes que indican la direcci´on, sin la parte de red del i-´esimo router para el que se miden las distancias. N´ umero de Distancias. 1 Byte para informar del n´ umero total de distancias que aparecer´an en el bloque para el i-´esimo router. Distancia j-´ esima. 1 Byte que da el valor de distancia a la cual se encuentra el o las redes que se enumeran a continuaci´on. N´ umero de Redes. 1 Byte para el n´ umero total de redes que est´an a la distancia j-´esima dada. Red k-´ esima a Distancia j-´ esima 1 a 3 Bytes usados para dar la direcci´on de red accesible usando el i-´esimo Siguiente Salto o router y que est´a a una distancia j-´esima. Los mensajes de accesibilidad vecina s´olo contienen un encabezado con un campo de tipo 5, un c´odigo de Hello y uno de Listen. Los mensajes de accesibilidad vecina tienen un campo tipo 3 y el c´odigo define el tipo de mensaje espec´ıfico. Un intervalo de tiempo denominado HELLO especifica la frecuencia con que los mensajes HELLO deber´ıan ser enviados, el intervalo de espera ejecuta la misma funci´on para mensajes de espera. Finalmente, un mensaje de espera tiene un campo de tipo 2. El campo c´odigo es usado para trasladar la informaci´on de accesibilidad de un vecino, existiendo tambi´en un c´odigo Hello y un Listen. Border Gateway Protocol (BGP) BGP es un protocolo de ruteo exterior para la comunicaci´on entre routers en diferentes ASs. BGP es el reemplazo para el antiguo EGP que se empleaba en ARPANET. La u ´ltima versi´on en desarrollo es la BGP Versi´on 4, desarrollada para soportar CIDR. Un sistema BGP intercambia informaci´on de c´omo alcanzar redes con otros sistemas BGP. Esta informaci´on incluye el camino completo de los ASs que el tr´afico debe recorrer para alcanzar dichas redes, y es adecuada para construir un grafo de conectividad entre ASs. De esta forma, es posible eliminar loops y tomar decisiones a la hora de rutear los paquetes.

161

En primer lugar, es necesario que el router pueda distinguir entre lo que es el tr´afico local y tr´afico en tr´ansito. El primero se origina en el AS y termina en ´este. El resto del tr´afico se considera en tr´ansito. Uno de los objetivos de BGP es reducir el tr´afico en tr´ansito. Un AS puede englobarse en uno de lo siguientes tipos: Terminal. Tiene una u ´nica conexi´on con otro AS y, por lo tanto, tiene tan s´olo tr´afico local. Multihome. Tiene conexi´on con varios ASs, pero rehusa transportar tr´afico en tr´ansito. De Tr´ ansito. Tiene conexi´on con m´as de un AS, y est´a destinado, bajo ciertas restricciones,a transportar tr´afico tanto local como en tr´ansito. La topolog´ıa de Internet queda dividida entonces, en ASs terminales, multihome y de tr´ansito. Los dos primeros no requieren BGP, sino que pueden utilizar EGP para intercambiar informaci´on con otros ASs. ´ BGP permite realizar un ruteo basado en pol´ıticas administrativas. Estas son fijadas por el administrador del AS y especificadas en los archivos de configuraci´on de BGP. Las pol´ıticas no forman parte del protocolo, pero las especificaciones de pol´ıtica permiten decidir entre distintos caminos cuando existen varias alternativas. Tambi´en controlan la forma en la que se transmite la informaci´on. La pol´ıtica vendr´a especificada en funci´on de requerimientos de fiabilidad, seguridad, etc. BGP se diferencia de RIP en que emplea TCP como protocolo de transporte, no UDP como es el caso de RIP. Dos sistemas que empleen BGP establecer´an una conexi´on TCP e intercambiar´an sus tablas BGP completas. En conexiones posteriores, se enviar´an actualizaciones de dichas tablas. BGP es un protocolo de vector de distancias, pero al contrario que RIP (que emplea como unidad de medida hops), BGP enumera las rutas a cada destino (la secuencia de ASs al destino) eliminando de esta forma, algunos de los problemas asociados con RIP. Cada AS tiene asociado un n´ umero de 16 bits. BGP detecta la fallo de un enlace o un host mediante el envio de un mensaje keepalive a sus vecinos de forma regular (aproximadamente cada 30 segundos). BGP involucra tres procedimientos funcionales, que son: Adquisici´ on de vecino. Dos routers son vecinos si est´an conectados a la misma subred y se han puesto de acuerdo en que ambos quieren intercambiar regularmente informaci´on de ruteo. Para llevar a cabo la adquisici´on de vecino, un router env´ıa a otro un mensaje

162

OPEN. Si el dispositivo destino acepta la solicitud, devuelve un mensaje KEEPALIVE como respuesta. Detecci´ on de vecino alcanzable. Una vez establecida la relaci´on de vecino, para mantener la relaci´on se realiza la detecci´on de vecino alcanzable envi´andose peri´odicamente mensajes KEEPALIVE. Detecci´ on de red alcanzable. Para la detecci´on de red alcanzable es necesario que cada dispositivo de encaminamiento tenga una base de datos con todas las redes que puede alcanzar y la mejor ruta para alcanzarla. Cuando se realiza un cambio en la base de datos es necesario enviar un mensaje UPDATE por difusi´on a todos los dispositivos de encaminamiento que implementan BGP para que puedan acumular y mantener la informaci´on necesaria. Todos los mensajes BGP tienen un encabezado de 19 bytes que consta de tres campos (Ver Figura 63a)): Marcador. 16 Bytes, sirve de autentificaci´on, es decir, para que el receptor pueda verificar la identidad del emisor. Longitud. 2 Bytes, indica el tama˜ no del mensaje en bytes. Tipo. 1 Byte que especifica el tipo de paquete enviado: Open, Update, Notification y Keepalive. Un mensaje que posea s´olo encabezado es un paquete Keepalive entre routers. Adem´as del encabezado, y dependiendo del tipo de mensaje, los campos que siguen son los siguientes en el caso de un mensaje Open (Figura 63b)): Versi´ on. 1 Byte para indicar la versi´on del protocolo, que puede ser 3 ´o 4. AS ID. 2 Bytes para el n´ umero de AS del emisor. Hold Time. 2 Bytes para el tiempo m´aximo en segundos que puede transcurrir entre la recepci´on de sucesivos mensajes KEEPALIVE y/o UPDATE y/o NOTIFICATION. BGP ID. 4 Bytes para el n´ umero u ´nico que identifica al AS. Corresponde a la direcci´on de red de cualquiera de sus interfases. Se usa el mismo n´ umero para todas ellas. C´ odigo de Autentificaci´ on. 1 Byte que define la interpretaci´on de del siguiente campo. BGP 3 s´olo define el c´odigo de autentificaci´on 0 (sin autentificaci´on). 163

1 By

1 By

1 By

1 By

Marcador

Largo

Tipo a)

Versión AS ID Hold Time BGP ID Auth Code Datos de Autentificación b) Largo Atributos Atributos de la ruta i-ésima Red c) Código

Subcódigo Datos d)

Figura 63: Estructura de un paquete BGP 3 a) Encabezado b) Paquete Open c) Paquete de Actualizaci´on d) Paquete de Notificaci´on.

Authentication Data. Campo de largo variable y se deduce a partir de la longitud del mensaje. Para el c´odigo 0, el dato se omite. Un mensaje de actualizaci´on BGP (Figura 63c)) tiene los siguientes campos: Largo de los Atributos. 2 Bytes para indicar la longitud del campo siguiente. Atributos de la Ruta. 3 o m´as Bytes para establecer las propiedades de las rutas que siguen a continuaci´on. Los posibles atributos son las pol´ıticas administrativas que se utilizar´an para el intercambio de informaci´on de ruteo entre ASs. i-´ esima Red. 4 Bytes para especificar el n´ umero de red de la i-´esima red descrita en el campo anterior. Las subredes y los hosts est´an inhabilitados expl´ıcitamente. 164

Finalmente, un mensaje de notificaci´on BGP (Figura 63d)) tiene los siguientes campos: C´ odigo. 1 Byte indicando el tipo de error asociado con alg´ un mensaje previo. Subc´ odigo. 1 Byte que proporciona informaci´on adicional al tipo de error que se est´a indicando. Datos. Informaci´on de longitud variable dependiente del c´odigo y del subc´odigo que se empleen para diagnosticar la causa del error.

3.6.

Dispositivos de Nivel de Red

3.6.1.

Router

Un router es un conmutador de paquetes que opera en el nivel de red del modelo OSI. Sus principales caracter´ısticas son: Permiten interconectar tanto redes de ´area local como redes de ´area extensa. Proporcionan un control del tr´afico y funciones de filtrado a nivel de red, es decir, trabajan con direcciones de nivel de red, como por ejemplo, con direcciones IP. Son capaces de rutear din´amicamente, es decir, son capaces de seleccionar el camino que debe seguir un paquete en el momento en el que les llega, teniendo en cuenta factores como l´ıneas m´as r´apidas, l´ıneas m´as baratas, l´ıneas menos saturadas, etc. Los routers son m´as “inteligentes” que los switches, pues operan a un nivel mayor lo que los hace ser capaces de procesar una mayor cantidad de informaci´on. Esta mayor inteligencia, sin embargo, requiere m´as procesador, lo que tambi´en los har´a m´as caros. A diferencia de los switches y bridges, que s´olo leen la direcci´on MAC, los routers analizan la informaci´on contenida en un paquete de red leyendo la direcci´on de red. Los routers leen cada paquete y lo env´ıan a trav´es del camino m´as eficiente posible al destino apropiado, seg´ un una serie de reglas recogidas en sus tablas. Los routers se utilizan a menudo para conectar redes geogr´aficamente separadas usando tecnolog´ıas WAN de relativa baja velocidad, como ISDN, una l´ınea T1, Frame Relay, etc. El router es entonces la conexi´on vital entre una red y el resto de las redes. Un router tambi´en sabe cu´ando mantener el tr´afico de la red local dentro de ´esta y cu´ando conectarlo con otras LANs, es decir, permite filtrar los broadcasts de nivel de enlace. Esto es bueno, por ejemplo, si un router realiza una conexi´on WAN, as´ı el tr´afico de broadcast de nivel 165

dos no es ruteado por el enlace WAN y se mantiene s´olo en la red local. Eso es especialmente importante en conexiones conmutadas como RDSI. Un router dispondr´a de una o m´as interfases de red local, las que le servir´an para conectar m´ ultiples redes locales usando protocolos de nivel de red. Eventualmente, tambi´en podr´a tener una o m´as interfases para soportar cualquier conexi´on WAN. 3.6.2.

Firewalls

Los Firewalls son barreras creadas entres redes privadas y redes p´ ublicas como por ejemplo, Internet. Originalmente, fueron dise˜ nados por los directores de inform´atica de las propias empresas, buscando una soluci´on de seguridad. En la actualidad, los sistemas de seguridad proporcionados por terceras empresas, son la soluci´on m´as escogida. Los Firewalls son simples en concepto, pero estructuralmente complejos. Examinan todo el tr´afico de entrada y salida, permitiendo el paso solamente al tr´afico autorizado. Se definen entonces ciertas pol´ıticas de seguridad las que son implementadas a trav´es de reglas en el firewall donde estas pol´ıticas t´ıpicamente se dise˜ nan de forma que todo lo que no es expresamente autorizado, es prohibido por defecto. Un Firewall protege la red interna de una organizaci´on, de los usuarios que residen en redes externas, permite el paso entre las dos redes a s´olo los paquetes de informaci´on autorizados y puede ser usado internamente, para formar una barrera de seguridad entre diferentes partes de una organizaci´on, como por ejemplo a estudiantes y usuarios administrativos de una universidad. Un Firewall de nivel de red permite un control de acceso b´asico y poco flexible, pues permite aceptar o denegar el acceso a un nodo bas´andose s´olo en la informaci´on que conoce a nivel de red. Es decir, se permite el acceso desde o hacia un nodo en forma total o simplemente no se permite. Por ejemplo, si una m´aquina es un servidor Web y a la vez servidor FTP, entonces puede resultar conveniente que s´olo algunos clientes tengan acceso al servicio FTP, y que todos tengan acceso al servicio Web. Este tipo de control no es posible con un Firewall de nivel de red, pues no existe forma de hacer la diferenciaci´on de servicios que existen en una misma m´aquina que, por lo tanto, tendr´a una misma direcci´on de red. La soluci´on a este problema se hace filtrando a niveles superiores al de red, con lo que se obtiene un Firewall flexible y eficiente, pero como desventaja se tiene un mayor consumo de procesador debido a la mayor cantidad de informaci´on que es necesario analizar. La Figura 64 muestra los equipos de nivel de red y su relaci´on con el modelo OSI y con equipos de niveles inferiores. 166

Capa Red

Capa de Enlace de Datos

Subcapa LLC Subcapa MAC

Capa Física

Modelo OSI

Figura 64: Equipos de Comunicaci´on de Nivel de Red.

3.7.

IPv6

El IETF empez´o a trabajar en 1990 para resolver de mejor forma el problema de la falta de direcciones IP, para ello se plante´o una nueva versi´on del protocolo IP llamada inicialmente IPng (Next Generation) y finalmente designada como IPv6 (versi´on 6) que est´a especificada en los RFCs 1883 y 2460. Los objetivos de dise˜ no planteados fueron los siguientes: Establecer un espacio de direcciones que no se agote en el futuro cercano. Reducir el tama˜ no de las tablas de ruteo y simplificar el protocolo para permitir a los routers procesar los paquetes m´as r´apidamente. Ofrecer mecanismos que permitan incorporar f´acilmente en el protocolo medidas de seguridad usando encriptaci´on. Permitir un mejor manejo de los diferentes tipos de servicio, para poder ofrecer garant´ıas de QoS y para permitir el uso de aplicaciones en tiempo real. Facilitar el uso de aplicaciones multicast. Permitir la movilidad de un host sin necesidad de cambiar su direcci´on. Contemplar un mecanismo que permita extender el protocolo en el futuro. Permitir la compatibilidad del protocolo nuevo con el viejo. 167

El tama˜ no de las direcciones IP a utilizar en IPv6 fue bastante discutido, y se plantearon alternativas que iban desde 8 hasta 20 bytes. Finalmente, la decisi´on final adopt´o un protocolo con direcciones de 16 bytes. IPv6, al igual que IPv4, ofrece un servicio de datagramas sin garant´ıas, es decir, “best effort”. De todas maneras, existen algunas opciones que permiten ofrecer QoS. Por otro lado, se debe hacer notar que IPv6 no es realmente compatible con IPv4 pues utiliza un formato de encabezado diferente, sin embargo, con peque˜ nas modificaciones puede lograrse compatibilidad. La implantaci´on del nuevo protocolo se realiza en forma gradual mediante la creaci´on de “redes islas” con IPv6. Para la interconexi´on de estas islas a trav´es del backbone IPv4 se utiliza tunneling de IPv6 en IPv4. La red experimental as´ı formada se conoce como 6Bone (http://www.6bone.net) y empez´o a funcionar en 1996. Los protocolos de ruteo se han tenido que modificar para tener en cuenta las caracter´ısticas propias y el nuevo formato de direcciones que utiliza IPv6, y por ejemplo, se han creado RIPv6 y OSPFv6. Las principales caracter´ısticas de IPv6 son: Direcciones de 16 Bytes, suficiente para todo futuro uso previsible. Encabezado simplificado, pasando de 13 a 8 campos, lo que permite disminuir el procesamiento en los routers. Mejor soporte de los campos opcionales del encabezado. Se han considerado los aspectos de seguridad como parte fundamental del protocolo. Mayor facilidad para especificar el tipo de servicio. 3.7.1.

Direcciones en IPv6

Las direcciones IPv6 est´an compuestas por 16 bytes. Los primeros bits identifican el tipo de direcci´on, de manera an´aloga a IPv4. Sin embargo, existen ahora muchas clases de direcciones, pero no todas tienen asignado el mismo rango, y la mayor´ıa est´an reservadas para usos futuros. Adem´as, se ha previsto un rango espec´ıfico para las direcciones IPv4, de esta forma, cualquier direcci´on IPv4 puede incluirse en un paquete IPv6. Una parte del espacio de direcciones se reserv´o para distribuci´on geogr´afica, de manera similar a como se hace actualmente con CIDR. Otra parte se reserv´o para repartir direcciones por proveedor. Se ha contemplado la posibilidad de que Internet evolucione hacia una red 168

que interconecte las redes de los grandes proveedores a nivel mundial, siendo secundaria en este caso la ubicaci´on geogr´afica. Para este caso se contempl´o una estructura de direcciones jer´arquica con varios niveles. Para las direcciones multicast se ha previsto un rango espec´ıfico, y en el formato de ´estas se reserv´o un campo de 4 bits que permite especificar el ´ambito que se pretende tenga la emisi´on. No se ha previsto ninguna direcci´on espec´ıfica para broadcast, ya que esto se considera un caso particular de multicast. Adem´as de env´ıos unicast, multicast y broadcast pueden hacerse env´ıos anycast, en los que un paquete se env´ıa a un miembro cualquiera de un grupo, sin importar ni especificar a cual. Esto permite, por ejemplo, acceder a un servidor multihomed haciendo balance de carga entre varias interfases, o por aquella que est´e m´as cerca del solicitante. Tambi´en facilita configuraciones redundantes donde un determinado servicio puede ser entregado por m´as de un servidor. Tambi´en se consider´o el caso de un rango de direcciones de significado local, equivalentes a las direcciones privadas, para casos en que por razones de seguridad se quiera estar completamente aislado del exterior. La notaci´on de las direcciones IPv6 es la siguiente: se escriben en ocho grupos de cuatro d´ıgitos hexadecimales, separados por dos puntos. Por ejemplo: 8000:0000:0000:0000:0123:4567:89AB:CDEF. Para abreviar la gran cantidad de ceros que tenga una direcci´on se puede utilizar una notaci´on abreviada, en la que los ceros a la izquierda pueden omitirse, y adem´as, si uno o m´as grupos tienen todos los d´ıgitos en cero se pueden omitir poniendo en su lugar dobles dos puntos. Volviendo al caso anterior: 8000::123:4567:89AB:CDEF. Para evitar ambig¨ uedades, la notaci´on abreviada :: s´olo puede utilizarse una vez en una direcci´on. Ya que el campo direcci´on en IPv6 es m´as largo, se puede reservar los seis u ´ltimos bytes de la direcci´on para incluir una parte local globalmente u ´nica en la direcci´on, que t´ıpicamente es una direcci´on MAC IEEE (esto es similar al direccionamiento usado en ATM), lo que permite la autoconfiguraci´on de los nodos, pues ´este fija la parte local de su direcci´on, y a partir de la direcci´on contenida en su tarjeta de red, escucha por el cable para que el router le informe de la parte de red, configurando autom´aticamente al nodo y garantizando que la direcci´on es u ´nica. 3.7.2.

Encabezado IPv6

Los campos que tiene el encabezado IPv6 se observan en la Figura 65 y su descripci´on es la siguiente: 169

Versión

Clase de Tráfico

Etiqueta de Flujo

Largo Carga Útil

Siguiente Encabezado

Límite de Saltos

Dirección Fuente

Dirección Destino

32 bits

Figura 65: Encabezado del Paquete IPv6.

Versi´ on. 4 bits y siempre vale 6. Este campo deber´ıa distinguir las versiones de IP, de forma que todas pudieran identificarse como un mismo protocolo a nivel de enlace con el mismo valor de Ethertype. Sin embargo, en la pr´actica muchas implementaciones de IPv4 no comprueban este campo sino que suponen que el paquete es IPv4 cuando el encabezado de nivel de enlace especifica protocolo IP. Por esto, a pesar de existir el campo versi´on es necesario asignar a IPv6 un valor propio en el nivel de enlace, como si se tratara de un protocolo diferente de IPv4. Clase de Tr´ afico. 1 Byte utilizado para especificar par´ametros de QoS de acuerdo a la especificaci´on de la arquitectura Differentiated Services. Los valores del 0 al 7 indican poca sensibilidad al tiempo lo que permite encolar el tr´afico. Los valores del 8 al 15 indican prioridad del tr´afico fuera de flujo por lo que no se puede encolar este tipo de tr´afico. Etiqueta de Flujo. 20 bits y permite identificar los paquetes que pertenecen a una sesi´on concreta entre dos hosts, usado t´ıpicamente para solicitar una determinada QoS. ´ Largo Carga Util. 2 Bytes que indican el tama˜ no del paquete en bytes, sin considerar los 40 Bytes de encabezado. Como el valor m´aximo codificable es 65535, el paquete m´aximo 170

ser´a de 65575. Siguiente Encabezado. 1 Byte que sirve para indicar si el encabezado est´a seguido por alguno de los encabezados opcionales. Si no existen opciones, este campo indica el protocolo de nivel de transporte al que pertenece el paquete, utilizando los mismos c´odigos que en IPv4 (Tabla 8). L´ımite Saltos. 1 Byte equivalente al campo TTL de IPv4, donde el m´aximo n´ umero de saltos especificables es 255. Direcci´ on Fuente. 16 Bytes para especificar la IPv6 del nodo fuente. Direcci´ on Destino. 16 Bytes para especificar la IPv6 del nodo destino. Los campos que han desaparecido son los siguientes: IHL pues el encabezado tiene largo fijo, Protocolo no es necesario debido a la funci´on del campo Siguiente Encabezado, Checksum pues el c´alculo del checksum en cada salto disminuye el rendimiento, adem´as de que la posibilidad de que se produzca un error en el nivel de red es baja, y adem´as el checksum proteg´ıa s´olo el encabezado y no los datos. Todos los campos relativos a fragmentaci´on han desaparecido porque en IPv6 la fragmentaci´on se controla mediante encabezados opcionales. Adem´as, en IPv6 todos los nodos han de aceptar paquetes de 576 bytes como m´ınimo y s´olo se permite la fragmentaci´on en el origen, es decir, el emisor debe generar paquetes suficientemente peque˜ nos para que puedan llegar a su destino sin fragmentaciones adicionales. Normalmente el emisor realizar´a el Path MTU Discovery, situaci´on que es habitual en muchas implementaciones de IPv4. En IPv6 se ha habilitado un mecanismo m´as flexible y eficiente que en IPv4 para soportar ´ los encabezados opcionales. Estos aparecen como encabezados adicionales al final del header est´andar, y su presencia queda indicada por el campo Siguiente Encabezado, que como ya se estableci´o, en caso de que no haya opciones indicar´a el protocolo de transporte. De esta forma, los campos opcionales en IPv6 pueden extenderse cuando se considere necesario proveyendo un mecanismo mediante el cual se puede indicar si las opciones deben ser procesadas por todos los routers del trayecto o s´olo por el u ´ltimo, lo que permite una reducci´on significativa del trabajo a desarrollar por los routers intermedios cuando se trata de una opci´on que s´olo debe ser procesada por el nivel de red en el host de destino. Cada paquete IPv6 incluye encabezados de extensi´on s´olo para los requerimientos necesarios del paquete. Cada encabezado de base y opcional contiene un campo Siguiente Encabezado para indicar el tipo del siguiente encabezado (ver Figura 66). Para extraer toda la informaci´on 171

Header IP Datos Nivel de Transporte

Sgte Encabezado: TCP a) Header IP

Header Routing

Sgte Encabezado: Routing

Sgte Encabezado: TCP

Datos Nivel de Transporte

b) Header IP

Header Routing

Sgte Encabezado: Routing

Sgte Encabezado: Authentication

Header Authentication Sgte Encabezado: TCP

Datos Nivel de Transporte

c)

Figura 66: Encabezados Opcionales de un Paquete IPv6 a) Sin Opciones b) Una Opci´on c) Dos Opciones.

del encabezado de un paquete IPv6 se requiere procesar secuencialmente todos los encabezados. Los routers intermedios no necesariamente necesitan procesarlos todos. Algunos tipos de encabezados IPv6 posibles son los siguientes: Salto-a-Salto. Entrega informaci´on que debe ser examinada por todos los routers por los que pase el paquete. Hasta el momento se ha definido s´olo una opci´on a este encabezado, y permite especificar paquetes de longitud superior a 64 KBytes, que pueden llegar a tener hasta 4 GBytes. Routing. Realiza las funciones combinadas de Strict y Loose Source Routing de IPv4. El m´aximo n´ umero de direcciones que puede especificarse es de 24. Fragment. Utilizada cuando se deba fragmentar un paquete. El mecanismo utilizado es similar al de IPv4, con la diferencia de que en IPv6 s´olo se permite la fragmentaci´on en el origen. De esta forma, se simplifica notablemente la complejidad de proceso en los routers. Authentication. Permite el uso de encriptaci´on para incorporar un mecanismo de firma digital por el cual el receptor del paquete puede estar seguro de la autenticidad del emisor. 172

Encrypted Security Payload. Permite el env´ıo de informaci´on encriptada que s´olo pueda ser le´ıda por el destinatario. La encriptaci´on afecta s´olo a los datos, ya que ´esta ha de ser le´ıda e interpretada por cada router por el que pasa.

3.8.

IP Cl´ asico sobre ATM

El transporte de cualquier protocolo de red en el modelo de sobrecapas de ATM envuelve dos aspectos b´asicos: encapsulaci´on de paquetes y resoluci´on de direcciones. Encapsulaci´ on de Paquetes Para poder permitir la reutilizaci´on de conexiones, debe existir un m´etodo para que un nodo que recibe un paquete de un nivel superior sepa que tipo de paquete ha recibido a trav´es de la red ATM y a que aplicaci´on debe pasarlo; por lo tanto, el paquete debe tener un prefijo con un campo de multiplexaci´on. El RFC 1483 define dos m´etodos para hacer esto: Encapsulaci´ on LLC/SNAP. En este m´etodo m´ ultiples protocolos pueden ser transportados en una sola conexi´on con el tipo de identificador de paquete encapsulado en el header LLC/SNAP est´andar. Todas las conexiones que usan estas encapsulaciones terminan en el nivel LLC dentro del sistema final, pues es all´ı donde ocurri´o la multiplexaci´on de paquetes. Multiplexaci´ on de Circuitos Virtuales. En este m´etodo un s´olo protocolo es transportado por la conexi´on ATM, con el tipo de protocolo impl´ıcitamente identificado en el establecimiento de la conexi´on. No se necesita, ni se transporta, un campo de multiplexaci´on o de tipo de paquete. Este tipo de encapsulaci´on es usada actualmente por LANE. Resoluci´ on de Direcciones Si se considera el caso de dos routers conectados por una red ATM, en el que uno de ellos recibe un paquete a trav´es de una interfaz LAN. En primer lugar revisar´a su tabla de direcciones para averiguar el siguiente salto. Si este resulta ser por medio de la interfaz ATM, entonces necesitar´a consultar una tabla de resoluci´on de direcciones para determinar la direcci´on ATM del siguiente router. El protocolo “IP Cl´asico sobre ATM” ha sido definido en el RFC 1577 para que soporte la resoluci´on din´amica de direcciones. Adem´as introduce el concepto de subred l´ogica IP (LIS) 173

que es un conjunto de nodos IP que se conectan a una red ATM y que comparten la misma subred IP. Para ejecutar la resoluci´on de direcciones dentro del LIS, cada LIS soporta un servidor ATMARP mientras que los nodos o clientes LIS son configurados con la direcci´on ATM del servidor ATMARP. Al inicializarse un nodo, en primer lugar se establece una conexi´on con ´ el servidor ATMARP. Este, al detectar la conexi´on transmite una petici´on de ARP inversa y obtiene la direcci´on IP y ATM del nodo, informaci´on que almacenar´a en su tabla. As´ı, cada nodo que desee resolver alguna direcci´on enviar´a una petici´on ATMARP al servidor, que devolver´a una respuesta ATMARP si conoce la direcci´on solicitada, caso contrario devuelve un ATMNAK.

Paso 1 : Ruteo: 144.254.10.X Directo 144.254.23.X vía 144.254.10.2 144.254.45.X vía 144.254.10.3 144.254.67.X vía 144.254.10.3

B

144.254.10.2

144.254.23.X

144.254.10.1 A

Servidor ARP

Red ATM

C

Paso 2 : Resolución de Direcciones 144.254.10.2 | A 144.254.10.3 | B

144.254.10.3

144.254.45.X

Paso 3 : Señalización crea conexión virtual entre routers Paso 4 : Envío de datos

144.254.67.X

Figura 67: Ruteo A Trav´es de ATM con el Modelo Cl´asico.

Una vez obtenida la direcci´on ATM el cliente LIS puede establecer la conexi´on con el nodo destino. La Figura (67) muestra la situaci´on expuesta. Next Hop Routing Protocol (NHRP) NHRP se construye sobre el modelo de IP cl´asico, sustituyendo el concepto de LIS por el 174

de red Non-Broadcast Multiple-Access (NBMA), esto es, una red tecnol´ogicamente similar a ATM, Frame Relay o X.25, que permite a m´ ultiples dispositivos unirse a la red, pero que no permite f´acilmente el mecanismo de broadcast de las LANs. La red consiste de un conjunto de nodos que se asocian a la misma red NBMA y que no est´an f´ısica o administrativamente restringidos para comunicarse directamente entre s´ı. En lugar de los servidores ARP, NHRP usa servidores NHRP, llamados NHS, que mantienen un cach´e de tablas de “resoluci´on de siguiente salto”, con las direcciones de los nodos asociados a un NHS en particular o para un conjunto de direcciones IP alcanzables a trav´es de routers servidos por el NHS. Los nodos son configurados con la direcci´on de su NHS y registran sus direcciones con ´el. NHS puede ser operado en dos modos. El primero es el modo servidor en que cada NHS dentro de la red NBMA es configurado est´aticamente con las direcciones de los destinos servidos por cada NHS en la red. El segundo es el modo f´abrica donde en NHS conoce los destinos servidos por otros NHS a trav´es del intercambio de informaci´on de ruteo intra e inter dominios. La forma de operaci´on es, en cualquiera de los dos casos, transparente para el usuario. NHS 2

NHS 3

NHS 1

Respuesta NH

Petición NH LIS 1

NHS 4

Red ATM LIS 2

LIS 3

LIS 4

Figura 68: Modo de Operaci´on de NHRP.

La forma en que opera el protocolo es la siguiente: cuando un nodo necesita transmitir un paquete a trav´es de la NBMA necesita resolver alguna direcci´on ATM en particular. Para esto, formula un petici´on NH a su NHS. Estos paquetes, al igual que todos los mensajes NHRP, son enviados en paquetes IP. Si la direcci´on de destino es servida por ese NHS, entonces retornar´a la direcci´on ATM 175

solicitada. En el caso contrario, el NHS consultar´a su tabla y determinar´a el siguiente NHS en la trayectoria y reenviar´a el paquete de petici´on. Este algoritmo es usado hasta que el NHS alcanzado conozca la direcci´on solicitada. Este nodo retorna una respuesta NH, que t´ıpicamente, viaja en orden inverso usando los mismos NHSs por los que lleg´o. Al llegar al nodo origen de la petici´on, ´este puede establecer una conexi´on directa para transmitir datos. La raz´on para que el paquete de respuesta NH viaje por el mismo camino de ida que de vuelta es para que cada NHS intermedio aprenda la direcci´on solicitada, mejorando el desempe˜ no y disminuyendo la latencia. La Figura (68) muestra el modo de operaci´on de NHRP en forma esquem´atica. NHRP utiliza tambi´en un n´ umero de caracter´ısticas opcionales, que incluyen grabaci´on de rutas para detectar loops y retrasos dentro de la NBMA.

176

4.

Tecnolog´ıas WAN

Físico

SMDS

Capas OSI

PPP

EIA/TIA-232,449 V.24 V.35 HSSI G.703 EIA-530

SDLC

MAC

HDLC

Enlace

F Relay

Red

LAPB

X.25

Introducci´ on

X.25

4.1.

Especificaciones WAN

Figura 69: Tecnolog´ıas WAN y Su Relaci´on con las Capas OSI

Una WAN es una red de comunicaci´on de datos que tiene una cobertura geogr´afica relativamente grande y suele utilizar las instalaciones de transmisi´on que ofrecen compa˜ n´ıas portadoras de servicios como las telef´onicas. Las tecnolog´ıas WAN operan en las tres capas inferiores del modelo OSI. La Figura 69 muestra algunas de las tecnolog´ıas WAN y el nivel OSI en el que operan. 4.1.1.

Capa F´ısica.

La capa f´ısica WAN describe la interfaz entre el equipo terminal de datos (DTE) y el equipo de conexi´on de los datos (DCE). T´ıpicamente, el DCE es el proveedor de servicio, y el DTE es el dispositivo asociado. En este modelo, los servicios ofrecidos al DTE se hacen disponibles a trav´es de un m´odem o unidad de servicio del canal/unidad de servicios de datos (CSU/DSU). Algunos est´andares de la capa f´ısica que especifican esta interfaz son: EIA/TIA-232D. Norma definida como interfaz est´andar para conectar un DTE a un DCE. EIA/TIA-449. Junto a la 422 y 423 forman la norma para transmisi´on serial que extienden las distancias y velocidades de transmisi´on m´as all´a de la norma 232. V.35. Seg´ un su definici´on original, servir´ıa para conectar un DTE a un DCE sincr´onico de banda ancha (anal´ogico) que operara en el intervalo de 48 a 168 Kbps. 177

X.21. Est´andar CCITT para redes de conmutaci´on de circuitos. Conecta un DTE al DCE de una red de datos p´ ublica. G.703. Recomendaciones del ITU-T, relativas a los aspectos generales de una interfaz. EIA-530. Presenta el mismo conjunto de se˜ nales que la EIA-232D. High-Speed Serial Interface (HSSI). Est´andar de red para las conexiones seriales de alta velocidad (hasta 52 Mbps) sobre conexiones WAN. 4.1.2.

Capa de Enlace

Las tecnolog´ıas m´as comunes en la capa de enlace de datos, asociadas con las l´ıneas seriales sincr´onicas se enumeran a continuaci´on: SDLC. Protocolo orientado desarrollado por IBM que define un ambiente WAN multipunto permitiendo que varias estaciones se conecten a un recurso dedicado. SDLC define una estaci´on primaria y una o m´as estaciones secundarias. La comunicaci´on siempre es entre la estaci´on primaria y una de sus estaciones secundarias. Las estaciones secundarias no pueden comunicarse entre s´ı directamente. HDLC. Est´andar ISO que no pudo ser compatible entre diversos vendedores por la forma en que cada vendedor ha elegido c´omo implementarla. HDLC soporta tanto configuraciones punto a punto como multipunto. LAPB. Utilizado sobre todo con X.25, puede tambi´en ser utilizado como transporte simple de enlace de datos. LAPB incluye capacidades para la detecci´on de p´erdida de secuencia o extrav´ıo de frames as´ı como tambi´en para intercambio, retransmitici´on, y reconocimiento de ´estos. Frame Relay. Utiliza l´ıneas digitales de alta calidad donde sea innecesario verificar los errores LAPB. Al utilizar un tipo de frame simplificado sin mecanismos de correcci´on de errores, Frame Relay puede enviar la informaci´on de la capa 2 muy r´apidamente, comparado con otros protocolos WAN. Point-to-Point Protocol. PPP contiene un campo de protocolo para identificar el protocolo de la capa de red. X.25. Define la conexi´on entre un terminal y una red de conmutaci´on de paquetes. 178

ISDN . Conjunto de servicios digitales que transmite voz y datos sobre las l´ıneas de tel´efono existentes. 4.1.3.

Tipos de Redes WAN

Redes P´ ublicas. Las redes p´ ublicas son recursos WAN pertenecientes a las compa˜ n´ıas de telecomunicaci´on que operan tanto en el pa´ıs como en el mundo. Estos recursos son ofrecidos a los usuarios a trav´es de suscripci´on. Estas operadoras incluyen a todas las compa˜ n´ıas de servicios de comunicaci´on local, las compa˜ n´ıas de servicios de comunicaci´on a larga distancia y los proveedores de servicios de valor agregado, quienes ofrecen con frecuencia, servicios de comunicaci´on WAN como complemento a su verdadero negocio. Redes Privadas. Una red privada es una red de comunicaciones privada construida, mantenida y controlada por la organizaci´on o compa˜ n´ıa a la que sirve. Como m´ınimo una red privada requiere sus propios equipos de conmutaci´on y de comunicaciones. Puede tambi´en, emplear sus propios servicios de comunicaci´on o alquilar los servicios de una red p´ ublica o de otras redes privadas que hayan construido sus propias l´ıneas de comunicaciones. Aunque una red privada es costosa, en compa˜ n´ıas donde la seguridad y el control sobre el tr´afico de datos son de alta prioridad, las l´ıneas privadas constituyen la u ´nica garant´ıa de un alto nivel de servicio. Adem´as, en situaciones donde el tr´afico de datos entre dos puntos remotos excede de seis horas al d´ıa, emplear una red privada puede ser m´as rentable que utilizar la red p´ ublica. 4.1.4.

Internetworking

Internetworking es una palabra creada para designar la interconexi´on de redes. La interconexi´on de redes consiste, en un contexto WAN, en el uso de enlaces WAN para comunicar distintas LANs distribuidas geogr´aficamente, quiz´as cada una con sus propios servidores. En este caso, en todas las redes se debe contar con un bridge o un router para enlaces WAN, que por un lado entreguen una interfaz hacia la WAN, y por otro, una interfaz hacia la LAN; pero en general, se utilizan routers para mejorar el rendimiento del enlace. La topolog´ıa de la red es una malla y en este tipo de interconexiones tambi´en puede tenerse cierta jerarqu´ıa donde existan redes que concentren varias redes m´as peque˜ nas y ´estas m´as importantes se interconecten entre s´ı.

179

Las tecnologias WAN m´as empleadas para la interconexi´on de redes son: l´ıneas dedicadas, Frame Relay, ISDN, y actualmente ATM, DSL y tecnolog´ıas inal´ambricas como WLL.

4.2. 4.2.1.

Tipos de Conexiones WAN Enlaces Punto-a-Punto

WAN

Figura 70: Esquema de Enlace Punto a Punto WAN

Un enlace punto a punto proporciona una u ´nica trayectoria entre dos nodos distantes, a trav´es de una red de transporte que t´ıpicamente es provista por alguna empresa de servicios. A este tipo de conexi´on sea les llama tambi´en l´ıneas privadas, debido a que la trayectoria establecida permanente y fija para cada red remota a la que se llega utilizando el enlace WAN. Las compa˜ n´ıas que proveen el servicio reservan varios enlaces punto a punto para uso exclusivo del cliente, proporcionando dos tipos de conexiones: transmisi´on de datagramas y transmisi´on de r´afagas de datos. La Figura 70 muestra un enlace punto a punto t´ıpico en una WAN. 4.2.2.

Conmutaci´ on de Circuitos y de Paquetes

La conmutaci´on de circuitos es un m´etodo de conmutaci´on WAN en el que se establece, mantiene y termina un circuito f´ısico dedicado a trav´es de una red de transporte para cada sesi´on de comunicaci´on. Al igual que los enlaces punto a punto, los circuitos conmutados manejan principalmente dos tipos de transmisiones: de datagramas y de r´afagas de datos. Este tipo de comunicaci´on es bastante utilizada por las compa˜ n´ıas de comunicaciones para la interconexi´on de enlaces, y su forma de operar es muy similar a la de una llamada telef´onica normal. ISDN es un ejemplo simple y cotidiano de tecnolog´ıa WAN de conmutaci´on de circuitos. La Figura 71 muestra un ejemplo de este tipo de tecnolog´ıa. La conmutaci´on de paquetes es un m´etodo de conmutaci´on WAN en el que los dispositivos de la red comparten un u ´nico enlace punto apunto para transferir los paquetes desde el origen hasta el destino a trav´es de la red de transporte. Se utiliza multiplexaje estad´ıstico para permitir que los dispositivos compartan los circuitos. ATM, Frame Relay y X.25 son ejemplos 180

DCE WAN DCE DCE

Figura 71: Conexi´on WAN de Circuitos Conmutados

DCE Demux WAN Mux DCE

Figura 72: Conexi´on WAN de Paquetes Conmutados

de tecnolog´ıa WAN de conmutaci´on de paquetes, y la Figura 72 muestra la transferencia de datos en una red de este tipo. 4.2.3.

Circuitos Virtuales WAN

Un circuito virtual es un circuito l´ogico creado para asegurar una comunicaci´on confiable entre dos dispositivos de red. Existen dos tipos de circuitos virtuales: los conmutados o SVCs y los permanentes o PVCs. Los primeros se establecen de forma din´amica por demanda y se terminan al finalizar la transmisi´on. Debido a eso se tienen tres fases o etapas en la comunicaci´on: el establecimiento del circuito (que implica la creaci´on de un circuito virtual entre origen y destino), la transferencia de datos entre los nodos finales, utilizando en circuito virtual establecido, y la terminaci´on del circuito que implica la desconexi´on. Por otro lado, los PVCs son establecidos de forma permanente, y s´olo constan de la fase de transmisi´on de datos. Los SVCs son utilizados en situaciones donde la transmisi´on de datos es espor´adica, debido a que ´estos incrementan demasiado el ancho de banda utilizado producto de las fases de

181

establecimiento y terminaci´on del circuito. Su principal ventaja es que disminuyen los costos asociados con la disponibilidad constante de un circuito virtual. Los PVCs son utilizados en situaciones donde la transferencia de datos entre los dispositivos es constante. Con los PVCs se disminuye el uso de ancho de banda asociado con el establecimiento y terminaci´on de los circuitos virtuales, pero se incrementan los costos debido a la constante disponibilidad del circuito virtual.

4.3.

Dispositivos WAN

WAN

Figura 73: Switches WAN Interconectando Routers

M´ odem. Un m´odem es un dispositivo que interpreta se˜ nales anal´ogicas y digitales, permitiendo de esta manera que los datos se transmitan a trav´es de l´ıneas telef´onicas. En el punto de origen las se˜ nales digitales son convertidas a una forma apropiada para su transmisi´on a trav´es de equipos de comunicaci´on an´alogos. En el destino, las se˜ nales anal´ogicas on convertidas de nuevo a su forma digital original. CSU/DSU. Una CSU (Unidad de Servicio de Canal)/DSU (Unidad de Servicio de Datos) es un dispositivo de interfaz digital que adapta la interfaz f´ısica de un DTE, como un nodo final, a la interfaz del dispositivo DCE, como un switch, en una red conmutada de transporte. La CSU/DSU tambi´en proporciona la temporizaci´on de la se˜ nal para la comunicaci´on entre los dispositivos. Adaptador ISDN. Un adaptador de terminal ISDN es un dispositivo que se utiliza para conectar la BRI de ISDN con otras interfaces. Un adaptador de terminal es, en esencia, un m´odem ISDN.

182

Switch WAN. Corresponde a un dispositivo multipuerto de interconectividad de redes que se utiliza en las redes de transporte. Por lo general, estos dispositivos conmutan tr´afico como el de Frame Relay, X.25 y SMDS y operan en la capa de enlace de datos. La Figura 73 muestra dos router ubicados en los extremos remotos de una WAN que se se encuentran conectados a trav´es de switches WAN. RAS. Un RAS o servidor de acceso remoto act´ ua como un punto de concentraci´on para conexiones de acceso hacia adentro y hacia afuera de una red. Gateway. Es cualquier dispositivo o software que permite la conexi´on entre nodos a un nivel superior al nivel de red. T´ıpicamente corresponde a un host que implemente la traducci´on de datos de dos o m´as stacks de protocolos, los que pueden ser iguales o diferentes.

4.4. 4.4.1.

Servicios de Conexi´ on WAN Bridging

DCE

WAN DCE DCE

Figura 74: Conexi´on de M´ ultiples LANs a Nivel de Enlace.

Cuando se desea conectar una LAN con otra usando un ambiente WAN, independientemente de la tecnolog´ıa WAN que se desee utilizar, surge la pregunta de a que nivel realizar la conexi´on. El bridging consiste en realizar la comunicaci´on en el nivel de enlace de las redes LAN, y utilizando para esto puentes remotos que permitan realizar la comunicaci´on. As´ı, un nodo se puede comunicar con cualquier otro e intercambiar informaci´on como si todos ellos estuvieran en la misma red local, la diferencia se har´a cuando la transferencia de informaci´on provenga de alg´ un nodo remoto, pues en ese caso la velocidad de transmisi´on se ver´a disminui-

183

da ya que generalmente los enlaces WAN son de menor velocidad que las que se alcanzan en una LAN. Este tipo de soluci´on consiste en tener las LANs conectadas por puentes remotos, que por un lado tienen la interfaz LAN tradicional (Ethernet/IEEE 802.3, Token Ring, etc.) y por el otro tienen, por ejemplo una interfaz serial V.35 o cualquier otra puerta o interfaz de comunicaciones que le permita conectarse a una red WAN. La situaci´on se explica en la Figura 74. La ventaja de usar este tipo de esquema es que resulta relativamente econ´omico de implementar. Adem´as de esto, su configuraci´on es simple, pues resulta plug and play ya que no es necesario configurar ninguna direcci´on ni protocolo de nivel de red en los clientes. No se requiere tampoco routers, pues si un frame necesita pasar de una LAN a otra, el bridge los reenviar´a, si es necesario, usando su forma normal de operar. La desventaja del esquema radica en que los protocolos de nivel de enlace son intensivos en el uso de broadcasting, por lo que los bridges retransmitir´an estos frames usando la conexi´on WAN y generando tr´afico adicional en ellos. LAN Ethernet

LAN Ethernet ATM

Capas Sup.

Capas Sup.

Red

Red

LLC MAC

LLC MAC

LLC

LLC

LLC MAC

LLC MAC

Físico

Físico

Físico

Físico

Físico

Físico

Figura 75: Conexi´on de Nodos en LANs Remotas Usando Bridging.

La Figura 75 muestra dos nodos remotos conectados a trav´es de un enlace ATM, utilizando protocolos LAN para comunicarse. Se observa entonces que la comunicaci´on, en el lado LAN siempre es a nivel de enlace. En cambio, la comunicaci´on WAN llega hasta el nivel de red. Los bridges son entonces elementos adaptadores y traductores entre las distintas tecnolog´ıas. El sistema global se observa como una u ´nica LAN cuya particularidad es que algunos nodos tienen una velocidad de transmisi´on y recepci´on que resulta ser menos a la tradicional, debido a que ´estos usan los enlaces WAN.

184

DCE

WAN DCE DCE

Figura 76: Conexi´on de M´ ultiples LANs a Nivel de Red.

4.4.2.

Routing

Una segunda forma de conectar las LANs es hacerlo a nivel de red, esta soluci´on se plantea en la Figura 76, donde se utilizan dispositivos de nivel de red para comunicar las distintas LANs. La ventajas que se obtienen son una mejor utilizaci´on de los enlaces, pues un router permite filtrar el tr´afico broadcast de nivel de enlace, y tambi´en se obtiene una organizaci´on l´ogica que ya no es plana como en el caso de poseer una sola LAN. Las desventajas de usar este tipo de esquema son contrarias a las ventajas del bridging, es decir, que resulta relativamente menos econ´omico y un poco m´as complejo de implementar. Esto porque un router es un dispositivo m´as caro que un bridge o switch, y porque se requerir´a de un nivel de abstracci´on y de orden mayor, pues ser´a necesario generar redes l´ogicas, configurar los clientes y dispositivos y crear las tablas de ruteo o activar protocolos de routing. LAN Ethernet con IP

LAN Ethernet con IP ATM

Capas 4a7

Capas 4a7

Red

Red

Red

Red

Red

Red

LLC MAC

LLC MAC

LLC

LLC

LLC MAC

LLC MAC

Físico

Físico

Físico

Físico

Físico

Físico

Figura 77: Conexi´on de Nodos en LANs Remotas Usando Routing.

La Figura 77 muestra dos nodos remotos conectados a trav´es de un enlace ATM, utilizando, 185

en este caso, un protocolo de nivel de red (IP) para comunicarse. La comunicaci´on, en el lado LAN, siempre es a nivel de enlace y de red. La comunicaci´on WAN llega hasta el nivel de red. Los router, en este caso, son los encargados de realizar las funciones de adaptaci´on y traducci´on. El sistema global se observa ahora como varias LANs comunicadas usando redes IP l´ogicas, en las que algunas de ellas tienen una velocidad de transmisi´on y recepci´on menor debido, nuevamente, a que ´estas usan los enlaces WAN. 4.4.3.

Acceso Remoto

Consiste en que los clientes, t´ıpicamente estaciones de trabajo o PCs, se encuentran distribuidos geogr´aficamente, y los servicios y servidores de red se encuentran concentrados en una LAN conocida normalmente como sitio central. La red central debe contar con un componente que permita a los usuarios remotos conectarse a ella. A este equipo se le conoce como servidor de acceso remoto o RAS, y su funci´on consiste en aceptar a os usuarios remotos y transformar la informaci´on que le llega a trav´es de los enlaces WAN, de manera tal que para la LAN central estos usuarios aparezcan como si estuvieran conectados en forma local. Generalmente, estos equipos son capaces de realizar bridging y routing, y disponen de una o varias interfaces WAN y una LAN. La topolog´ıa es en general de tipo estrella donde el nodo central es la red principal, y las tecnolog´ıas WAN m´as empleadas son del tipo conmutaci´on de circuitos como: acceso telef´onico con modems e ISDN.

Modem

PSTN/ISDN Modem

RAS

Modem

Figura 78: RAS Conectando M´ ultiples Clientes a una LAN.

Un caso particular, y conocido, de acceso remoto es el acceso a Internet, donde el proveedor de Internet cuenta con un RAS y su LAN se encuentra interconectada mediante un enlace dedicado Internet. La Figura 78 muestra una conexi´on RAS a una red LAN desde m´ ultiples clientes usando acceso conmutado. 186

4.4.4.

Servicios de Marcado

Los servicios de marcados son un m´etodo de interconectividad WAN cuyas implementaciones m´as comunes son los servicios de ruteo en demanda usando discado y el de respaldo con discado. El ruteo en demanda usando discado o DDR es una t´ecnica por medio de la cual un router puede iniciar y terminar de manera din´amica, una sesi´on de conmutaci´on de circuitos a medida que las estaciones terminales de transmisi´on lo requieran. El router se configura para que considere un cierto tipo de tr´afico como interesante (como el tr´afico de alg´ un protocolo en particular) y el resto como no interesante. Cuando el router recibe tr´afico interesante destinado a la red remota, se establece un circuito y se transmite a destino en forma normal. Si se recibe tr´afico no interesante, y ya estaba establecido el circuito en ese momento, ese tr´afico tambi´en se rutea a destino. El router maneja un timer que se reinicia s´olo cuando se recibe tr´afico interesante. Sin embargo, el circuito se termina si el router recibe tr´afico no interesante antes de que el timer expire. De la misma forma, si se recibe tr´afico no interesante y no existe ning´ un circuito, el router elimina el tr´afico. El DDR se utiliza como reemplazo para enlaces punto a punto y servicios WAN multiacceso conmutado. La implementaci´on de respaldo con discado es un servicio que activa una l´ınea serial de respaldo bajo determinadas condiciones. La l´ınea serial secundaria puede actuar como un enlace de respaldo que se utiliza cuando el enlace principal falla o puede actuar tambi´en como una fuente que proporciona ancho de banda adicional cuando la carga en el enlace principal alcanza un cierto umbral. El respaldo de marcaci´on proporciona protecci´on contra la degradaci´on del desempe˜ no y disminuye el tiempo fuera de servicio de una WAN. 4.4.5.

Tunneling

En las conexiones WAN se desea enviar paquetes de un protocolo determinado a trav´es de una red de otro tipo, sabiendo que en el lado del receptor se dispone de una red del mismo protocolo que el emisor. Por ejemplo, al utilizar ATM como transporte de datos TCP/IP, lo que se hace es introducir los paquetes IP en el campo de datos de una celda ATM. La t´ecnica descrita en el ejemplo anterior se denomina encapsulado o tunneling, ya que la uni´on puede verse como un t´ unel que permite intercambiar paquetes de un protocolo determinado de forma que no sean “vistos” por el protocolo intermedio. Los t´ uneles se utilizan en Internet para interconectar las zonas con routing multicast constituyendo la red MBone. Tambi´en se utilizan t´ uneles para interconectar las zonas de Internet que funcionan con el protocolo IPv6, 187

constituyendo la red 6Bone. Recientemente se ha definido en Internet un est´andar para la creaci´on de t´ uneles denominado L2TP (Layer 2 Tunneling Protocol, RFC 2661). Esto permite la creaci´on de redes privadas virtuales (VPN, Virtual Private Network) a trav´es de una red p´ ublica como Internet, mejorando notablemente las caracter´ısticas de la comunicaci´on desde el punto de vista de seguridad. El tunneling supone una p´erdida de rendimiento, ya que el paquete viaja con doble cantidad de encabezados. Sin embargo, puede ser una soluci´on muy interesante debido a su sencillez cuando se trata de enviar poco tr´afico, o para conexiones temporales. 4.4.6.

Virtual Private Network (VPN)

Aunque el desempe˜ no de Internet es, generalmente, una barrera para usarla como WAN para la mayor´ıa de las aplicaciones cr´ıticas, Virtual Private Network permite enviar datos importantes a trav´es de Internet en forma segura y eficaz. En una configuraci´on VPN, los clientes y servidores que componen la red virtual se conectan a Internet de manera tradicional: dial-up, ISDN, l´ıneas dedicadas, cable-modem, etc. Cada nodo de la “red dentro de la red” encripta los datos que env´ıa a otras ubicaciones de la red virtual. A medida que los datos encriptados atraviesan Internet, se ven como porciones de datos sin sentido y si alg´ un intruso trataran de detectar estos datos, no podr´a leer el contenido sin poseer las claves para desencriptar los datos. Cliente VPN Internet Tunneling Modem

ISP

Router VPN

Figura 79: Conexi´on VPN entre Cliente ISP y Router VPN de una Compa˜ n´ıa.

Esta soluci´on es atractiva para las compa˜ n´ıas, ya que el acceso a Internet es significativamente menos costoso que el uso tradicional de l´ıneas dedicadas. Se pueden usar VPNs para comunicar sucursales o habilitar clientes m´oviles, o acceder a servidores desde cualquier ubicaci´on. Al unir dos sitios con una conFiguraci´on VPN, cada punto de entrada de la debe tener un dispositivo de acceso a VPN, por ejemplo, un firewall o router que soporte VPN. Las claves 188

de encriptaci´on de VPN son compartidas por clientes y servidores. Estas claves permiten a los nodos en la VPN encriptar datos para que s´olo puedan ser le´ıdos por otros miembros de las mismas redes virtuales. En VPN se utilizan distintos esquemas de encriptaci´on. Uno de los m´as populares son L2TP (Layer 2 Tunneling Protocol) de Microsoft y Cisco, un standard que est´a siendo desarrollado por IETF (Internet Engineering Task Force). En este, como en cualquier otro esquema de encriptaci´on por intercambio de claves, ´estas necesitan ser distribuidas a los clientes remotos y sitios para permitir la interoperabilidad. El flujo de datos de la encriptaci´on y desencriptaci´on en la VPN es una tarea muy intensiva con respecto a CPU. Cuando los datos llegan al nodo VPN, se debe controlar que los datos provienen de otro nodo de la red virtual. Si es as´ı, el nodo receptor (router, firewall, o unidad VPN dedicada) debe desencriptar los datos antes de pasarlos a su destino en la red local. Por lo tanto, al dise˜ nar una VPN, la interoperabilidad debe ser la consideraci´on m´as importante y deben dimensionarse adecuadamente los dispositivos de entrada.

189

5.

Nivel de Transporte

5.1.

Introducci´ on

El nivel de transporte es el nivel m´as importante desde el punto de vista de las comunicaciones. La tarea de este nivel es proporcionar un transporte de datos confiable y econ´omico desde el origen al destino, independiente de la red o redes f´ısicas en uso. Esta capa proporciona un servicio a los procesos de la capa de aplicaci´on, en el caso de del modelo TCP/IP y a los de sesi´on en el caso de OSI. Para lograr este objetivo la capa de transporte hace uso de los servicios de la capa de red. El hardware o el software de la capa de transporte que se encarga del trabajo se llama entidad de trasporte. Esta entidad puede estar en el kernel del sistema operativo, en un proceso de usuario independiente, en un paquete de biblioteca que forma parte de las aplicaciones de la red o en la interfaz de red de una m´aquina. En algunos casos, la red portadora puede proporcionar servicio de transporte confiable, en cuyo caso la entidad de transporte reside en m´aquinas especiales de interfaz en la orilla de la subred a la que se conectan los hosts. En el nivel de transporte existen dos tipos de servicios: orientados a la conexi´on y no orientado a la conexi´on. Lo normal es trabajar con servicios orientados a la conexi´on donde se tienen, como siempre, tres fases: establecimiento, transferencia de datos y desconexi´on. Adem´as, tanto el direccionamiento como el control de flujo son semejantes a los de las otras capas. Lo mismo ocurre con los servicios no orientados a la conexi´on. As´ı como la unidad b´asica de intercambio de informaci´on a nivel de enlace se llama frame, la del nivel de red es llamada paquete, la unidad de transferencia del nivel de transporte se llama TPDU (Transport Protocol Data Unit) en la nomenclatura OSI, mensaje o datagrama en el caso de usarse el protocolo UDP (servicio no orientado a conexi´on) y segmento en el caso de usarse el protocolo TCP (servicio orientado a conexi´on). De todas formas, se debe comentar que no existe una nomenclatura clara y general para la unidad m´ınima del nivel de transporte. La necesidad de un nivel de transporte es debida a que los usuarios no tienen control sobre la subred, que es de lo que se encarga el nivel de red; y es por este motivo no se pueden resolver los problemas de un mal servicio usando mejores routers o incluyendo una porci´on mayor del manejo de errores en la capa de enlace de datos. La u ´nica posibilidad entonces es poner el nivel de transporte encima del nivel de red para mejorar la calidad del servicio. Con esto, si a la mitad de una transmisi´on se informa a una entidad de transporte que su conexi´on de red ha sido terminada abruptamente y sin indicaci´on de lo sucedido a los datos 190

actualmente en tr´ansito, la entidad de transporte puede establecer una nueva conexi´on de red con la entidad de transporte remota. Usando esta nueva conexi´on de red, la entidad puede enviar una solicitud a su igual preguntando qu´e datos llegaron y poder reiniciarse desde la interrupci´on la transmisi´on de los datos que no hayan llegado. La existencia del nivel de transporte hace posible que el servicio de transporte sea m´as confiable que el de red. El nivel de transporte puede detectar y compensar paquetes perdidos y datos alterados. Es m´as, las primitivas del servicio de transporte pueden dise˜ narse de modo que sean independientes de las primitivas del servicio de red, que pueden variar seg´ un las redes, pudiendo escribir programas de aplicaci´on usando un est´andar de primitivas que puedan trabajar en una variedad amplia de redes, sin tener que preocuparse por las interfaces de subred. Por lo tanto, esta capa cumple la funci´on clave de aislar las capas superiores respecto de la tecnolog´ıa, el dise˜ no y las imperfecciones de la subred. Entre las funciones que realiza la capa de transporte se pueden contar: Se encarga de la comunicaci´on entre dos nodos, independiz´andola de como funciona la red. Lograr que la informaci´on llegue de la m´aquina A a la m´aquina B libre de errores y en orden(el nivel de red se encargaba de la comunicaci´on entre el nodo A y el nodo B). Dividir o segmentar los datos que llegan desde el nivel superior. Multiplexar varias conexiones de transporte sobre una misma conexi´on de red para reducir el costo. Determinar el tipo de servicio que debe dar a la capa superior. Este se determina cuando se establece la conexi´on. Administrar varios enlaces simult´aneos entre varias m´aquinas. En los host multiproceso, puede haber m´ ultiples conexiones, en el header de este nivel se indica a qu´e conexi´on pertenece cada mensaje. Establecer y liberar las conexiones a trav´es de la red y del control de flujo entre hosts. 5.1.1.

Direccionamiento

Cuando un proceso de aplicaci´on desea establecer una conexi´on con un proceso de aplicaci´on remoto, debe especificar a cu´al debe conectarse. La situaci´on es ahora diferente a las 191

situaciones de direccionamiento vistas en las capas de enlace y red, pues en ellas se identificaba con una u ´nica direcci´on a un nodo o equipo completo, en cambio ahora, en el nivel de transporte ya se tiene esas direcciones (las de red y de enlace), pero para ese u ´nico host es necesario definir m´ ultiples direcciones l´ogicas las que albergar´an finalmente m´ ultiples servicios. Es decir, la situaci´on es an´aloga a lo que ocurre en un edificio de varios pisos y con varios departamentos (que representar´ıa un nodo o host en una red), la direcci´on de red ser´ıa la calle donde est´a ubicado el edificio, la direcci´on de nivel de enlace ser´ıa el n´ umero del edificio en la calle, y la direcci´on de transporte ser´ıa el n´ umero de departamento dentro del edificio. Esta forma de organizaci´on permite que en un nodo “vivan” (como en el edificio) m´ ultiples servicios, lo que hace por ejemplo que una misma m´aquina sea servidor Web, correo, FTP, LDAP, etc. De esta forma, el m´etodo que normalmente se emplea es definir direcciones de transporte en las que los procesos pueden estar a la escucha de solicitudes de conexi´on. Estas direcciones son los llamados TSAP (Transport Service Access Point). Una direcci´on TSAP puede ser una direcci´on jer´arquica en la que se puede distinguir que la direcci´on consiste de una secuencia de campos usados para dividir en partes el espacio de direcciones, como en el caso de un n´ umero telef´onico donde f´acilmente se puede observar la organizaci´on en niveles. Una alternativa al espacio jer´arquico de direcciones es el espacio plano, donde se necesita de un servidor de nombres que tome las direcciones de puerto como entrada y devuelva direcciones de red como salida. Es decir, un nodo solicita el servicio, y el ente encargado de la traducci´on de nombres es el que consulta su tabla para enviar la petici´on a alg´ un nodo respectivo en la red. El esquema de conexi´on m´as empleado es el utilizado por los hosts UNIX de Internet, y se llama protocolo inicial de conexi´on. En este protocolo cada m´aquina que desea ofrecer servicio a usuarios remotos tiene un servidor de procesos especial, el daemon inetd, que act´ ua como receptor de los servidores y escucha en un grupo de TSAP al mismo tiempo, esperando una solicitud de conexi´on, en este caso, del protocolo TCP. Los usuarios potenciales de un servicio emiten una solicitud de conexi´on especificando la direcci´on TSAP del servicio que desean acceder. La direcci´on TSAP, en este caso, es llamada puerto TCP. Tras obtener la solicitud entrante, el servidor de procesos genera el servidor solicitado, permiti´endole heredar la conexi´on con el usuario existente y el servidor de procesos retorna a escuchar solicitudes nuevas. Por ejemplo, cada vez que un proceso cliente desea conectarse a un servidor para leer el correo electr´onico, se hace la llamada a la direcci´on IP del servidor de correos, pero para poder acceder al servicio POP3, que es uno de los protocolos que permite leer correo electr´onico, se debe especificar la direcci´on TSAP que accesa al servicio. En este caso, la 192

direcci´on TSAP o puerto TCP de conexi´on es el 110. As´ı, si se desea hacer una conexi´on a un servidor de correos POP3 puede ejecutarse el programa telnet de la siguiente forma: telnet A.B.C.D 110 donde A.B.C.D es la IP del servidor. Muchas implementaciones TCP/IP disponen de una API

2

para la programaci´on de apli-

caciones que es denominada socket. Un socket es una estructura de software que opera como un punto terminal de comunicaciones en un dispositivo de red. Los sockets son una interfaz multiprotocolo, es decir, soporta TCP, UDP y otros protocolos. Los sockets son la API m´as extendida en programaci´on de aplicaciones TCP/IP y forman un est´andar de facto. Existen implementaciones para muchos sistemas operativos. La filosof´ıa b´asica de los sockets deriva directamente del sistema de entrada/salida de UNIX, con ampliaciones que permiten por ejemplo a un proceso servidor ponerse “a la escucha”. 5.1.2.

Primitivas de Servicio de Transporte

Las primitivas del servicio de transporte permiten a los usuarios del nivel el acceso al servicio de transporte. El servicio de transporte es parecido al servicio de red, pero existen algunas diferencias importantes. La principal es que la intenci´on del servicio de red es modelar el servicio ofrecido por las redes reales, que pueden perder paquetes, por lo que generalmente no es un servicio confiable. El servicio de transporte orientado a la conexi´on, en cambio, s´ı es confiable, aunque el nivel de red tenga errores el nivel de transporte proporciona un servicio confiable por una red no confiable. Otra diferencia entre el servicio de red y el de transporte radica en los usuarios a los que se dirigen los servicio. El servicio de red lo usan s´olo las entidades de transporte, pocos usuarios llegan a este nivel. Sin embargo, muchos programas pueden usar primitivas de transporte, con lo que el servicio de transporte debe ser c´omodo y sencillo de usar. Las primitivas de transporte son ejecutadas por la entidad de transporte enviando un paquete al servidor. Encapsulado en la carga u ´til de este paquete hay un mensaje del nivel de transporte para la entidad de transporte del servidor.

5.2.

Elementos de Protocolos de Transporte

El nivel de transporte se parece al nivel de enlace en que debe ocuparse de la comunicaci´on punto a punto. Por ejemplo, este nivel debe ocuparse del control de errores (incluyendo men2

Una API (Application Program Interface) es simplemente un conjunto de reglas de programaci´on que

determinan como una aplicaci´on debe acceder a un servicio.

193

sajes perdidos o duplicados) y el control de flujo, al igual que el nivel de transporte, y aunque las t´ecnicas que se aplican son parecidas, existen importantes diferencias entre los niveles, motivadas por el hecho de que en el nivel de enlace hay un s´olo hilo f´ısico (o su equivalente) entre las dos entidades que se est´an comunicando, mientras que en el nivel de transporte hay toda una red de transporte bajo de ´el. Las mayores diferencias entre el nivel de transporte y el de enlace son las siguientes: El retardo que se observa en el nivel de transporte es normalmente mucho mayor y sobre todo m´as variable (mayor jitter) que en el de enlace. En el nivel de enlace el medio f´ısico entre las dos entidades tiene una capacidad de almacenamiento de informaci´on normalmente muy reducida y siempre la misma. En el de transporte los routers intermedios pueden tener una capacidad considerable y esta puede variar con el estado de la red. En el nivel de enlace se asegura que los frames llegar´an al receptor en el mismo orden que han salido del emisor (salvo que se pierdan, en cuyo caso no llegar´an). En el nivel de transporte esto es cierto s´olo cuando se utiliza un servicio orientado a la conexi´on en el nivel de red. Si se utiliza un servicio no orientado a conexi´on el receptor podr´ıa recibir los datos en orden distinto al de emisi´on. En el nivel de enlace las dos entidades se ven directamente (suponiendo una comunicaci´on d´ uplex) lo que permite que el emisor sepa en todo momento si el receptor est´a operativo, y el receptor sabe que los datos recibidos corresponden todos a una misma sesi´on del emisor. En el nivel de transporte la comunicaci´on es indirecta, el emisor podr´ıa enviar datos, quedar fuera de servicio y m´as tarde entrar en funcionamiento otra vez. Si no se adoptan las medidas oportunas el receptor podr´ıa recibir todos esos datos sin siquiera percatarse de que corresponden a dos sesiones distintas del emisor o incluso podr´ıan pertenecer a dos usuarios distintos. Establecimiento de una Conexi´ on Para establecer una conexi´on el cliente emite un TPDU de petici´on de conexi´on, y el servidor responde con un TPDU de aceptaci´on y a partir de ese momento puede empezar el intercambio de datos. Sin embargo, existen una serie de complicaciones a considerar. En el nivel de transporte puede haber una gran fluctuaci´on en el tiempo que tardan en llegar los TPDUs a su destino. Estos pueden perderse o llegar duplicados, ya que si el emisor 194

no recibe confirmaci´on reenviar´a el mismo TPDU pasado el timeout. Por ejemplo, un cliente intercambia una serie de TPDUs con un servidor, y cuando ya ha terminado la transacci´on cierra la sesi´on. Segundos m´as tarde, pero desde otro origen, perfectamente puede aparecer la misma secuencia de TPDUs del cliente anterior, duplicadas por el otro origen, y que llegan ´ al servidor de nuevo. Este realizar´ıa la misma transacci´on otra vez. Para evitar este tipo de problemas, se utiliza para establecer la conexi´on un mecanismo de three-way handshake con n´ umeros de secuencia . La idea es que el servidor s´olo aceptar´a la conexi´on despu´es de haber pedido al cliente confirmaci´on de que desea realizarla. La soluci´on a este problema es el siguiente: tanto el cliente como el servidor utilizan un protocolo de ventana deslizante para el env´ıo de los TPDUs, para lo cual emplean un n´ umero de secuencia. A diferencia del n´ umero de secuencia del nivel de enlace, el del nivel de transporte emplea rangos mayores. Por ejemplo, en TCP el n´ umero de secuencia se almacena en un campo de 32 bits, con lo que es un n´ umero de hasta 4 Gigas. Tanto el cliente como el servidor eligen de forma aleatoria o pseudoaleatoria el valor inicial del n´ umero de secuencia que van a utilizar, cada uno por separado para cada sentido de la comunicaci´on. El cliente informa al servidor en su primer TPDU del n´ umero de secuencia elegido, y por su parte el servidor le responde en otro TPDU con el n´ umero de secuencia elegido por ´el, incluyendo en ´este un ACK piggybacked del TPDU recibido. De esta forma, si el servidor recibe un TPDU de petici´on de conexi´on a una conexi´on preexistente, responder´a con un TPDU al cliente en la que pondr´a en el campo ACK el n´ umero de secuencia recibido. Cuando la respuesta llegue al cliente ´este ver´a que ese n´ umero no corresponde con ninguna conexi´on que ´el tuviera pendiente de confirmaci´on, por lo que rechazar´a la conexi´on. El servidor por su parte esperar´a recibir en el campo ACK del siguiente TPDU un valor que corresponda con el que ´el ha enviado en el anterior. Esta t´ecnica evita tambi´en el riesgo de que un proceso cliente que cae por alg´ un motivo utilice la misma conexi´on cuando reaparece m´as tarde, ya que normalmente el nuevo proceso intentar´a utilizar un n´ umero de secuencia diferente. Esta es una medida de seguridad ya que el nuevo proceso cliente podr´ıa pertenecer, por ejemplo, a otro usuario. Generalmente se establece una vida m´axima para los TPDUs en la red, y de esta forma se reduce el riesgo de recibir duplicados retrasados. Cuando un nodo cae y vuelve a subir se recomienda esperar al menos el tiempo de vida de un TPDUs antes de activar el nivel de transporte. As´ı, es imposible que un TPDU de la sesi´on anterior pueda aparecer por alguna parte cuando se inicia la sesi´on nueva. En Internet el tiempo de vida m´aximo recomendado de las TPDUs es de 2 minutos, y se controla mediante el campo TTL en el paquete IP. 195

Una vez establecidos los n´ umeros de secuencia es posible utilizar para el intercambio de TPDUs cualquier protocolo de ventana deslizante. A diferencia del nivel de enlace, en el nivel de transporte se suelen numerar bytes no frames, ya que el tama˜ no de los TPDUs puede ser muy variable. Para las retransmisiones se puede utilizar tanto retroceso n como repetici´on selectiva. Terminaci´ on de una Conexi´ on Una conexi´on puede terminarse de forma sim´etrica o asim´etrica. La terminaci´on asim´etrica es unilateral, es decir uno de los dos hosts decide terminar y termina la conexi´on en ambos sentidos. En la terminaci´on sim´etrica cada host corta la conexi´on u ´nicamente en el sentido en el que emite datos. Se puede considerar entonces la terminaci´on sim´etrica como dos circuitos simplex donde cada uno es controlado por el emisor. La terminaci´on asim´etrica se considera anormal y puede provocar la p´erdida de informaci´on, ya que cuando un host ha enviado un TPDU de desconexi´on ya no acepta m´as datos. Entretanto, el otro host podr´ıa haber enviado un TPDU de datos que no ser´a aceptado. En la terminaci´on sim´etrica el host 1 invita al host 2 a desconectarse mediante un DISCONNECT REQUEST. El host 2 responde con otro DISCONNECT REQUEST, al cual el host 1 responde con TPDU ACK y cierra la conexi´on. Por su parte, el host 2 cerrar´a la conexi´on al recibir el TPDU ACK. Por este mecanismo se asegura que no se pierden TPDUs en ruta ya que ambos hosts tienen aviso previo de la desconexi´on y dan su conformidad expl´ıcitamente. Este mecanismo supone el intercambio de tres mensajes de forma an´aloga al proceso de conexi´on, por lo que tambi´en se denomina three-way handshake. No existe forma fiable de terminar la conexi´on en menos mensajes sin correr el riesgo de perder datos. Si se pierde alg´ un TPDUs de desconexi´on el mecanismo de handshake falla, pues los hosts se quedan esperando eternamente la respuesta. Para evitar esto se utiliza un mecanismo de timeouts que resuelve el problema reenviando el TPDU perdido si se trata de un DISCONNECT REQUEST, o cerrando la conexi´on por timeout cuando lo que se ha perdido es el TPDU ACK. Existen muchas circunstancias que pueden provocar que una conexi´on se quede medio abierta. Por ejemplo, un host puede quedar fuera de servicio sin previo aviso y el otro, que ten´ıa una conexi´on abierta con ´el, quedar a la espera sin saber que ha ocurrido. Para resolver estas situaciones se prevee normalmente un tiempo m´aximo durante el cual una conexi´on puede estar abierta sin tr´afico, pasado ese tiempo los hosts se env´ıan mensajes de prueba (denominados keep-alive en TCP) para comprobar que el otro lado a´ un responde. Los valores 196

de timeout para el env´ıo de mensajes keep-alive son grandes, por ejemplo, la documentaci´on de TCP sugiere 2 horas como valor por defecto. Control de Flujo y de Buffers El control de flujo en el nivel de transporte es fundamental, ya que la velocidad con que los datos llegan al receptor puede ser muy variable al intervenir multitud de factores. Si se utilizan protocolos de ventana deslizante, entonces la asignaci´on de buffers est´atica para cada conexi´on no es apropiada, debido a que el n´ umero de conexiones simult´aneas puede variar mucho al no haber una interfaz f´ısica asociada a cada conexi´on. Por este motivo la asignaci´on de espacio para buffers en el nivel de transporte tiene dos caracter´ısticas: primero el lugar espacio de buffers es com´ un y compartido por todas las conexiones, ya sean entrantes o salientes. Segundo, el reparto del espacio entre las conexiones activas se hace de forma din´amica de acuerdo con las necesidades. En todo momento cada conexi´on tiene asignado un espacio para emisi´on y uno para recepci´on. El de emisi´on est´a ocupado con TPDUs pendientes de ser enviados o de confirmaci´on, y el de recepci´on tiene una parte ocupada con TPDUs recibidos pendientes de ser aceptadas por el nivel de aplicaci´on, y otra libre reservada para TPDUs que puedan llegar del otro host. Otra diferencia con respecto al nivel de enlace es que, mientras que el tama˜ no de los frames suele ser constante para una conexi´on f´ısica dada, el tama˜ no de los TPDUs puede ser muy variable. Para optimizar la utilizaci´on del espacio se asignan segmentos de buffer de longitud variable. Para una m´axima flexibilidad en este sentido tanto los n´ umeros de secuencia como los tama˜ nos de ventana cuentan generalmente bytes, no TPDUs. La parte de buffer que el receptor tiene reservada para TPDUs que puedan llegarle es anunciada al emisor regularmente, para que ´este sepa que cantidad de datos esta dispuesto a aceptar el receptor. Este espacio puede fluctuar mucho con el tiempo en funci´on de la actividad que tenga esa y el resto de conexiones que mantenga el host. Con este modo de funcionamiento el receptor realmente controla la situaci´on, ya que si indica una ventana cero el emisor tendr´a que esperar y no enviarle datos mientras el receptor no le anuncie una ventana mayor. Multiplexaci´ on Generalmente el nivel de transporte es el encargado de multiplexar la diferentes conexiones solicitadas por el nivel de aplicaci´on en una u ´nica conexi´on a nivel de red. Esto se conoce como multiplexaci´on hacia arriba, ya que visto en el modelo de capas supone que varias direcciones del nivel de transporte confluyan en una u ´nica direcci´on del nivel 197

de red. En redes no orientadas a conexi´on, como IP, el nivel de transporte suele ocuparse de multiplexar el tr´afico de las diferentes aplicaciones y usuarios en una u ´nica direcci´on a nivel de red.

5.3.

Protocolos TCP y UDP

5.3.1.

Protocolo TCP

TCP (Transmission Control Protocol) es el protocolo de transporte confiable utilizado en Internet en el nivel de transporte. Este protocolo ha adquirido su popularidad gracias a las caracter´ısticas que presenta: Protocolo Orientado a Conexi´ on. Las aplicaciones solicitan la conexi´on al destino y luego usan esta conexi´on para entregar y transferir los datos, garantizando que ´estos ser´an entregados sin problema. Punto a Punto. Una conexi´on TCP tiene dos extremos, que son los entes que participan en la comunicaci´on, es decir, emisor y receptor. Confiabilidad. TCP garantiza que los datos transferidos ser´an entregados sin ninguna p´erdida, duplicaci´on o errores de transmisi´on. Full D´ uplex. Los extremos que participan en una conexi´on TCP pueden intercambiar datos en ambas direcciones simult´aneamente. Conexi´ on de Inicio Confiable. El uso del three-way handshake garantiza una condici´on de inicio confiable y sincronizada entre los extremos de la conexi´on. T´ ermino de Conexi´ on Aceptable. TCP garantiza la entrega de todos los datos antes de la finalizaci´on de la conexi´on. Debido a que TCP, al igual que UDP, est´a en la capa de transporte, necesita valerse de IP para el env´ıo de sus segmentos o mensajes. De esta manera, IP trata al mensaje TCP como la informaci´on que debe entregar y en ning´ un momento intenta interpretar su contenido, como generalmente se hace al pasar un mensaje de una capa a otra inferior. Los extremos de la conexi´on son identificados por puertos, lo garantiza que se puedan establecer m´ ultiples conexiones en cada host y que los puertos puedan estar asociados con una aplicaci´on o un puerto directamente. De lo anterior se desprende que los routers o cualquier dispositivo de nivel tres s´olo puede observar los encabezados IP (nivel de red) para el reenv´ıo de los datagramas, 198

y nunca interpretar´an los datos de un nivel superior, pues esto supone violar el modelo de capas. Por lo tanto, TCP en la m´aquina destino, es el encargado de interpretar los mensajes TCP, despu´es de recibirlos de la capa de red, quien previamente le ha quitado el encabezado IP. TCP usa diversas t´ecnicas para proveer la entrega confiable de datos. Estas t´ecnicas permiten a TCP recobrarse de errores como paquetes perdidos, duplicados, retardo, diferentes velocidades de transmisi´on entre nodos y congesti´on. Paquetes perdidos. TCP usa confirmaci´on positiva con retrasmisi´on para lograr la entrega de datos confiable. De este modo, el receptor env´ıa mensajes de control de confirmaci´on (ACK) al emisor para verificar la recepci´on exitosa de la informaci´on. A su vez, el emisor inicializa un timer al transmitir la informaci´on. Si el timer expira antes que la confirmaci´on llegue, el emisor debe retransmitir la informaci´on inicializando un nuevo timer. Paquetes duplicados. Si el receptor recibe un paquete duplicado no lo toma en cuenta y procede a su descarte, ya que ´este habr´a sido tomado y marcado como recibido. Retardo de paquetes. Si un paquete no es recibido y el siguiente s´ı, el receptor no mueve la ventana deslizante hasta que el segmento faltante sea recibido. De esta manera el receptor al no recibir el ACK correspondiente al paquete retrasado lo reenv´ıa. Diferentes velocidades de transmisi´ on. Al establecer la conexi´on TCP, tanto el emisor como el receptor indican cual es su capacidad de almacenamiento intermedio (l´ease buffers) para acordar cual ser´a la velocidad a la cual la transmisi´on se llevar´a a cabo. Congesti´ on. TCP implementa una pol´ıtica en la cual mantiene una ventana para medir la congesti´on, cada vez que un temporizador expira, ´esta ventana es reducida. Para la decisi´on de env´ıo de datos, el emisor toma en cuenta el tama˜ no de esta ventana para crear el tama˜ no de la ventana deslizante de datos. Para proveer transparencia, cada aplicaci´on entrega arbitrariamente toda la informaci´on como un flujo de datos, luego TCP se encarga de separar esta informaci´on en segmentos, cada uno de los cuales tiene a lo m´as el tama˜ no de un paquete IP. El flujo dado por la aplicaci´on es numerado por la cantidad de bytes transferidos, y cada uno de estos segmentos contiene un n´ umero de secuencia de los bytes de informaci´on. As´ı, el receptor env´ıa un segmento con

199

el n´ umero de secuencia de la informaci´on confirmada, no de los segmentos. Los ACKs son acumulativos, de esta manera un ACK puede ser la confirmaci´on de varios segmentos. Para poder sintonizar el timeout de TCP, ´este debe estar basado en el round trip time (RTT) que tenga un paquete de red, ya que si es menor que ´este se crear´a un tr´afico innecesario y no habr´a comunicaci´on entre los extremos de la conexi´on. Sin embargo, existe un problema: el emisor no puede saber de antemano en RTT de ning´ un paquete antes de la transmisi´on. Debido a esto, el emisor usa un timeout de retransmisi´on (RTO) obtenido de RTTs previos. Esto es un m´etodo espec´ıfico llamado algoritmo de retransmisi´on adaptativo RT Tactual = αRT Tanterior + (1 − α)RT Tmedido RT O = βRT Tactual

(1)

donde α debe estar entre 0.8 y 0.9 y β entre 0.1 y 0.2. El RTT es medido observando la diferencia entre el tiempo de transmisi´on y la llegada de una confirmaci´on. Debido a que el tr´afico excesivo que pueda presentar una red es una de las causas de la p´erdida de paquetes, algunos protocolos como TCP, proveen la retransmisi´on como mecanismo para garantizar la llegada de los mensajes. Esta soluci´on m´as que una buena soluci´on es un arma de doble filo, ya que la retransmisi´on excesiva puede contribuir a la congesti´on. La p´erdida de paquetes es interpretada por TCP como un indicador de congesti´on. El mecanismo de control de TCP es usado por el nodo emisor para detectar el nivel de congesti´on y si ´este est´a sobre un cierto nivel umbral considerado el m´aximo aceptable, la retransmisi´on de paquetes es reducida. El mecanismo utilizado consiste en que un host env´ıa un paquete, y si una confirmaci´on llega sin perdida, el emisor env´ıa dos paquetes y comienza a aumentar la ventana en potencias de dos. Cuando TCP env´ıa un n´ umero de paquetes igual a la mitad del tama˜ no de una ventana, la tasa de incremento disminuye hasta recibir las confirmaciones de los paquetes enviados. Puertos TCP Un puerto es un n´ umero entero entre 0 y 65535 (lo que corresponde a un n´ umero entero positivo de 16 bits) que especifica la direcci´on TSAP a la cual se dirige una conexi´on TCP o UDP. En un mismo host, un n´ umero de puerto puede ser utilizado simult´aneamente por una aplicaci´on para UDP y por otra para TCP, lo que no plantea ning´ un conflicto, ya que son TSAPs diferentes. Por convenio los n´ umeros 0 a 1023 est´an reservados para el uso de servicios est´andar, por lo que se les denomina puertos bien conocidos (well-known ports). Cualquier n´ umero por

200

Tabla 13: Algunos Puertos TCP/UDP Est´andar. Puerto

Aplicaci´on Descripci´on

9

Discard

Descarta todos los datos recibidos (para pruebas)

19

Chargen

Intercambio de strings (para pruebas)

20

FTP-Data

Transferencia de datos en FTP

21

FTP

Intercambio de informaci´on de control en FTP

22

SSH

Sesi´on remota segura en una m´aquina

23

Telnet

Sesi´on remota en una m´aquina

25

SMTP

Env´ıo de mails a trav´es de servidor de correos

53

DNS

Consultas y transferencia de datos de servicio de nombres

80

HTTP

Protocolo HTTP para intercambio de p´aginas web

110

POP3

Lectura de correo electr´onico

139

NetBIOS

Intercambio de datos usando NetBIOS en redes locales con Windows

143

IMAP

Lectura de correo electr´onico

179

BGP

Sesi´on de intercambio de informaci´on del protocolo BGP

443

HTTPS

Protocolo HTTP para intercambio de p´aginas web seguras

encima de 1023 est´a disponible para ser utilizado libremente por los usuarios. En la tabla 13 se presentan algunos algunos de los puertos m´as utilizados. As´ı pues, una conexi´on de dos entidades usuarias del nivel de transporte se especifica por la combinaci´on: IPemisor : P uertoemisor ↔ IPreceptor : P uertoreceptor . El programa netstat sirve como ayuda para conocer que puertos y con que nodos est´a conectada una m´aquina en particular. Por ejemplo: C:\>netstat Active Connections Proto

Local Address Foreign Address

State

TCP

jorgep:1479

DALI:netbios-ssn

ESTABLISHED

TCP

jorgep:2897

lovecraft.die.udec.cl:22

ESTABLISHED

TCP

jorgep:2903

conan.die.udec.cl:telnet

ESTABLISHED

TCP

jorgep:2882

manet.die.udec.cl:smtp

ESTABLISHED

UDP

jorgep:2888

vangogh.die.udec.cl:domain

ESTABLISHED

201

En este caso, el nodo local denominado jorgep est´a conectado a la m´aquina DALI transfiriendo datos utilizando el Entorno de Red de Windows, el puerto local en el PC es el 1479, mientras que el servicio lo obtiene desde el puerto 139 (NetBIOS-ssn). Adem´as, esta m´aquina est´a conectada a lovecraft.die.udec.cl mediante ssh y a conan.die.udec.cl v´ıa telnet (puertos 22 y 23) usando los puertos locales 2897 y 2903. Tambi´en puede observarse una conexi´on de env´ıo de mail, usando SMTP en el puerto 25 del servidor de correos. Las conexiones son todas TCP, salvo la u ´ltima que es una consulta DNS hecha al puerto 53 del servidor de nombres usando UDP.

Puerto Origen

Puerto Destino Número de Secuencia Número de ACK

HLEN

HLEN

Tamaño Ventana

Checksum

Puntero de Datos Urgente Opciones (0 o más palabras) Datos

Figura 80: Encabezado de un Segmento TCP.

Encabezado TCP La Figura 80 muestra el encabezado de un segmento TCP, la descripci´on de sus campos es la siguiente: Puerto Origen y Destino. 2 Bytes cada uno que identifican los puertos que se van a utilizar en cada host para comunicar con las aplicaciones que intercambian datos. N´ umero de Secuencia. 4 Bytes, indican el n´ umero de secuencia que corresponde, en la conexi´on, al primer byte que se env´ıa en el campo datos de ese segmento.

202

N´ umero de ACK. 4 Bytes que apuntan al n´ umero de secuencia del primer byte del pr´oximo segmento que se espera recibir del otro lado. Longitud de Encabezado TCP. 4 bits que especifican el largo del encabezado, en palabras de 32 bits. Este valor no incluye el campo datos, y el campo opciones hace que esta longitud pueda variar. Bits de Codificaci´ on. 6 bits que se presentan a continuaci´on de 6 bits no utilizados. Corresponden a bits flag, cuyo nombre y significado es el siguiente: URG (urgent, sirve para indicar que el segmento contiene datos urgentes, y el campo puntero de datos urgentes contiene la direcci´on donde terminan ´estos), ACK (acknowledgement, indica que en este segmento el campo N´ umero de ACK tiene el significado habitual , de lo contrario carece de significado; en la pr´actica, el bit ACK esta a 1 siempre, excepto en el primer segmento enviado por el host que inicia la conexi´on), PSH (push, indica que el segmento contiene datos PUSHED, es decir, que deben ser enviados r´apidamente a la aplicaci´on correspondiente sin esperar a acumular varios segmentos), RST (reset, usado para indicar que se debe abortar una conexi´on porque se ha detectado un error de cualquier tipo), SYN (synchronize, este bit indica que se est´a estableciendo la conexi´on y est´a puesto en 1 s´olo en el primer mensaje enviado por cada uno de los dos hosts en el inicio de la conexi´on) y FIN (finish, indica que no se tienen m´as datos que enviar y que se quiere cerrar la conexi´on; se usa ya que para que una conexi´on se cierre de manera normal cada host ha de enviar un segmento con el bit FIN puesto en 1) Tama˜ no de Ventana. 2 Bytes que indican la cantidad de bytes que se est´a dispuesto a aceptar del otro lado en cada momento. Mediante este par´ametro el receptor establece un control de flujo sobre el flujo de datos que puede enviar el emisor. Checksum. 2 Bytes y sirve para detectar errores en el segmento recibido. Estos podr´ıan ser debidos a errores de transmisi´on no detectados, a fallos en los equipos o a problemas en el software. Puntero de Datos Urgentes. 2 Bytes, indican el final de un flujo de datos de tipo urgente, ya que el segmento podr´ıa contener datos no urgentes. TCP no marca el principio de los datos urgentes, es responsabilidad de la aplicaci´on averiguarlo. Opciones. Cero o m´as Bytes que habilitan un mecanismo por el cual es posible incluir extensiones al protocolo. Entre las m´as interesantes se encuentran las siguientes: tama˜ no 203

m´aximo de segmento, uso de repetici´on selectiva (en vez de retroceso n), uso de NAK (acuse de recibo negativo en caso de no recepci´on de un segmento), uso de ventana mayor de 64 KBytes mediante el empleo de un factor de escala.

Figura 81: Esquema de un Segmento TCP Real.

La Figura 81 muestra el encabezado de un segmento TCP real, capturado en una conexi´on de lectura de correo electr´onico desde un cliente (puerto cliente: 1606) al servidor (puerto cliente: 110). En ella se observan los valores de n´ umero de secuencia, acknowledge, los flags del segmento, el tama˜ no de la ventana, etc. 5.3.2.

Protocolo UDP

TCP tiene la robustez y funcionalidades propias de un protocolo de transporte orientado a conexi´on; sin embargo esa robustez y funcionalidad tienen aparejadas una cierta complejidad. Por ejemplo, cualquier transmisi´on de informaci´on TCP requiere como m´ınimo el intercambio de seis mensajes para establecer la comunicaci´on y terminarla. Adem´as, mientras una conexi´on existe ocupa una serie de recursos en el host que est´a llev´andola a cabo.

204

En determinadas oportunidades no se requiere toda la funcionalidad que TCP provee en las conexiones, m´as a´ un, cualquier transmisi´on de informaci´on TCP presenta el retardo ya comentado de seis mensajes como m´ınimo, lo que puede llegar a ser significativo para alguna aplicaci´on determinada. Por esto, en algunos casos se prefiere que el nivel de transporte preste un servicio m´as sencillo, no orientado a conexi´on y no confiable. Algunos ejemplos de situaciones en las que es m´as conveniente un servicio no orientado a conexi´on son: aplicaciones tiempo real como audio o video, donde no se puede tolerar el retardo producido por los ACK, consultas a servidores en que se requiere el env´ıo de uno o dos mensajes u ´nicamente como es el caso del DNS, etc. UDP (User Datagrama Protocol) es el protocolo no orientado a conexi´on de Internet y entre las aplicaciones que utilizan UDP se encuentran TFTP (Trivial File Transfer Protocol), DNS (Domain Name Server), SNMP (Simple Network Management Protocol), NTP (Network Time Protocol), NFS (Network File System) , etc. Los TPDUs intercambiados por UDP se denominan mensajes o datagramas UDP. Una de las caracter´ısticas m´as interesantes de UDP es que puede ser utilizado por aplicaciones que necesitan soporte de tr´afico multicast o broadcast. Con TCP esto no es posible debido a la naturaleza punto a punto, orientada a conexi´on del protocolo. UDP no suministra ning´ un mecanismo de control de flujo o control de congesti´on. Cuando lo que se env´ıa es u ´nicamente un mensaje esto es innecesario, ya que presumiblemente un mensaje aislado no crear´a problemas de congesti´on y ser´a siempre aceptado en destino. Si se desea enviar un flujo de mensajes, por ejemplo video o audio en tiempo real, se deber´an tomar las medidas adecuadas para asegurar la capacidad suficiente en la red y evitar la congesti´on no excediendo lo solicitado en el momento de hacer la reserva. En caso de congesti´on en la red parte de los datagramas ser´an descartados por la red sin informar por ning´ un mecanismo al emisor, ni al receptor. En caso de saturaci´on del receptor, ´este sencillamente ignorar´a los datagramas que no pueda aceptar. En algunos casos, se contemplan a nivel de aplicaci´on mecanismos de control que permiten al receptor detectar si se producen p´erdidas (por ejemplo, numerando los datagramas) informando al emisor para que baje el ritmo de emisi´on si se supera un umbral determinado. Puertos y Encabezado UDP De forma similar a los segmentos TCP, los datagramas UDP se dirigen a la aplicaci´on adecuada mediante el puerto de destino, especificado en el encabezado. An´alogamente a TCP los puertos UDP se identifican mediante un campo de 16 bits (n´ umeros entre 0 y 65535). A´ un 205

en el caso de coincidir en n´ umero con un puerto TCP son TSAPs diferentes. Al igual que en TCP los valores por debajo de 1024 est´an reservados para los puertos bien conocidos, aunque su significado es diferente en la mayor´ıa de los casos Puerto Origen

Puerto Destino Número de Secuencia Número de ACK Datos (0 hasta 65507 By) 32 bits

Figura 82: Encabezado de un Datagrama UDP.

La Figura 82 muestra el encabezado de un datagrama UDP, la descripci´on de sus campos es la siguiente: Puerto Origen y Destino. 2 Bytes cada uno, que especifican el puerto de la aplicaci´on que genera y recibe el mensaje. A diferencia de TCP, el campo origen valdr´a normalmente cero, salvo que la aplicaci´on solicite una respuesta. Longitud. 2 Bytes que indican la longitud del mensaje, incluyendo los campos de encabezado. Checksum. 2 Bytes. Su uso es opcional en IPv4 y obligatorio en IPv6, ya que en ese caso se ha suprimido el checksum a nivel de red. Cuando se env´ıa informaci´on en tiempo real su uso puede omitirse. Si la verificaci´on del checksum en el receptor arroja un error, el mensaje es descartado sin notificarlo al nivel de aplicaci´on ni al emisor. Datos. contiene los datos a transmitir. De la misma forma que un host o un router pueden tener que fragmentar un datagrama que contenga un segmento TCP, es posible que el host emisor o alg´ un router intermedio tengan que fragmentar un mensaje UDP porque sea mayor que la MTU permitida en la red por la que ha de enviarse. An´alogamente a los segmentos TCP la fragmentaci´on ocurre de forma transparente a UDP y el encabezado del mensaje s´olo aparecer´a en el primer fragmento. En cambio, cada fragmento deber´a incluir un nuevo encabezado IP. 206

Figura 83: Esquema de un Datagrama UDP Real.

La Figura 83 muestra el encabezado de un mensaje UDP real que pertenece a una consulta DNS 3 . La conexi´on se lleva a cabo desde un cliente que utiliza el puerto 1609 y realiza la petici´on al servidor cuyo puerto destino es el 53. Se observan en la Figura los otros campos, largo (42 Bytes) y el CRC.

3

El servicio DNS es aquel encargado de hacer las traducciones entre nombres y direcciones IP, y mediante

una consulta de este tipo un programa cualquiera sabe que la direcci´on www.die.udec.cl corresponde a la IP 152.74.21.3

207

Referencias [1] Computer Networks. Andrew Tanenbaum. Prentice Hall PTR, Third Edition. 1996. [2] Tecnolog´ıas de Interconectividad de Redes. Merilee Ford, H. Kim Lew, Steve Spanier, Tim Stevenson. Prentice Hall, Primera Edici´on. 1998. [3] Internetworking LANs and WANs. Gilbert Held. Wiley Communications Technology, First Edition. 1995. [4] Data and Computer Communications. William Stalling. Prentice Hall, Fifth Edition. 1997. [5] Tecnolog´ıas Emergentes Para Redes de Computadores. Uyless Black. Prentice Hall. 2000. [6] Apuntes Redes de Ordenadores, Rogelio Monta˜ nana P´erez, Universidad de Valencia, Espa˜ na. [7] Apuntes Redes de Computadoras (Teor´ıa y Taller), Emilio Hern´andez, Universidad Sim´on Bolivar, Venezuela. [8] Apuntes Redes de Datos, Eduardo Rivera, Universidad de Concepci´on, Chile. [9] Apuntes Redes de Datos, Marcelo Iribarren, Universidad de Concepci´on, Chile. [10] Apuntes Redes de Datos, Marcelo Maraboli, Universidad T´ecnica Federico Santa Mar´ıa, Chile. [11] Interconexi´ on de Sistemas Abiertos, Jos´e Nu˜ nez, Universidad del Pa´ıs Vasco, Espa˜ na. [12] A Technical Tutorial on the IEEE 802.11 Standard, Pablo Brener, BreezeCom Wireless Communications, 1996. [13] Charles Spurgeon’s Ethernet (IEEE 802.3) Web Site http://www.ots.utexas.edu/ethernet/ [14] Raj Jain - Professor of Computer and Information Science http://www.cis.ohio-state.edu/ jain/

208

[15] Rogelio Monta˜ nana - Profesor Asociado Departamento de Inform´ atica de la Universidad de Valencia http://www.uv.es/ montanan/ [16] Cisco - Internetworking Technology Overview http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito doc/index.htm [17] IETF RFCs http://www.ietf.org/rfc/ [18] Internet Histories http://www.isoc.org/internet/history/

209