Diseño y Arquitectura de Redes Telemáticas

210
Diseño y Arquitectura de Redes Telemáticas José Alberto Incera Diéguez (Última actualización: Abr 2018)

Transcript of Diseño y Arquitectura de Redes Telemáticas

Page 1: Diseño y Arquitectura de Redes Telemáticas

Diseño y Arquitecturade Redes Telemáticas

José Alberto Incera Diéguez

(Última actualización: Abr 2018)

Page 2: Diseño y Arquitectura de Redes Telemáticas
Page 3: Diseño y Arquitectura de Redes Telemáticas

Presentación

Este documento contiene el material de apoyo para el curso Diseño y Arquitectura deRedes que se imparte en el Instituto Tecnológico Autónomo de México.

La estructura del material en la primera parte sigue básicamente la propuesta de dise-ño descendente presentada por Priscilla Oppenheimer1 la cual ha sido ampliada y com-plementada con otras referencias bibliográficas, y a partir de nuestra propia experienciaprofesional.

En la segunda parte se presentan algunas tecnologías para el diseño de redes de accesoy de transporte. También se introducen nuevas tecnologías de redes definidas por software.

En la tercera parte se presenta material para analizar la viabilidad financiera de unproyecto de redes.

El material ha sido integrado a lo largo de varios años de impartir estas materias enlos niveles de licenciatura, maestría y diplomado. En él han participado varios profesores,entre los que cabe destacar: Dr. Uciel Fragoso, Dr. José A. Incera, Dr. Marcelo Mejía,Mtro. Javier Salido y Mtro. Enrique Weitzel.

1Oppenheimer, P., Top-Down Network Design, 2nd Ed., Cisco Press, 2004, ISBN: 1587051524

I

Page 4: Diseño y Arquitectura de Redes Telemáticas
Page 5: Diseño y Arquitectura de Redes Telemáticas

Índice general

1. Metodología de diseño de redes 1

1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Diseño descendente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Microsoft Solutions Framework . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1. Modelo de proceso . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4. Análisis de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.4.1. Manejo de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4.2. Caso de estudio: cuantificación del riesgo . . . . . . . . . . . . . 25

1.5. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2. Requerimientos técnicos 35

2.1. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3. Confiabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.4. Desempeño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.4.1. Ancho de banda . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.4.2. Utilización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4.3. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.4. Tasa de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.5. Eficiencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.6. Retardo y variabilidad . . . . . . . . . . . . . . . . . . . . . . . 44

2.5. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.6. Administración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.7. Facilidad de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.8. Adaptabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.9. Costo-beneficio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

III

Page 6: Diseño y Arquitectura de Redes Telemáticas

2.10. Conflictos entre requerimientos . . . . . . . . . . . . . . . . . . . . . . . 53

2.11. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3. Caracterización de la red 59

3.1. Caracterización de la topología . . . . . . . . . . . . . . . . . . . . . . . 60

3.1.1. Mapa de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.1.2. Asignación de nombres y direcciones . . . . . . . . . . . . . . . 62

3.1.3. Caracterización de los medios de transmisión . . . . . . . . . . . 62

3.1.4. Restricciones ambientales y arquitectónicas . . . . . . . . . . . . 63

3.2. Desempeño de la red actual . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.2.1. Herramientas de recolección . . . . . . . . . . . . . . . . . . . . 64

3.2.2. Periodo y frecuencia de recolección . . . . . . . . . . . . . . . . 66

3.2.3. Algunas métricas de desempeño . . . . . . . . . . . . . . . . . . 67

3.2.4. Presentación de resultados . . . . . . . . . . . . . . . . . . . . . 69

3.2.5. Análisis estadístico de redes . . . . . . . . . . . . . . . . . . . . 70

3.3. Caracterización del flujo . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.3.1. Tipos de flujo por aplicación . . . . . . . . . . . . . . . . . . . . 75

3.3.2. Caracterización del volumen de tráfico . . . . . . . . . . . . . . . 77

3.3.3. Requerimientos de calidad de servicio . . . . . . . . . . . . . . . 82

3.4. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4. Diseño lógico 87

4.1. Diseño de la topología . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.1.1. Topología plana . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.1.2. Diseño jerárquico . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.2. Diseño de la capa de acceso . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.2.1. Problema de Localización-asignación . . . . . . . . . . . . . . . 91

4.2.2. Asignación de nodos a concentradores . . . . . . . . . . . . . . . 93

4.2.3. Topología de nodos a concentrador . . . . . . . . . . . . . . . . 94

4.3. Capa de distribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.4. Diseño de la red dorsal . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.4.1. Diseño de la topología . . . . . . . . . . . . . . . . . . . . . . . 101

4.5. Diseño basado en bloques modulares . . . . . . . . . . . . . . . . . . . . 106

4.6. Topologías con redundancia . . . . . . . . . . . . . . . . . . . . . . . . 107

IV

Page 7: Diseño y Arquitectura de Redes Telemáticas

4.7. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5. Administración 119

5.1. Evolución de administración de sistemas . . . . . . . . . . . . . . . . . . 120

5.1.1. Gestión de fallas . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.1.2. Gestión de configuración . . . . . . . . . . . . . . . . . . . . . . 121

5.1.3. Gestión de seguridad . . . . . . . . . . . . . . . . . . . . . . . . 122

5.1.4. Gestión de rendimiento . . . . . . . . . . . . . . . . . . . . . . . 122

5.1.5. Contabilidad de recursos . . . . . . . . . . . . . . . . . . . . . . 123

5.2. Protocolos de administración . . . . . . . . . . . . . . . . . . . . . . . . 123

5.2.1. Modelo de administración OSI . . . . . . . . . . . . . . . . . . . 123

5.2.2. Modelo de gestión IETF . . . . . . . . . . . . . . . . . . . . . . 124

5.2.3. Simple Network Management Protocol . . . . . . . . . . . . . . 125

5.2.4. Base de datos de información de administración (MIB) . . . . . . 127

5.3. RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.4. Administración de sistemas con SNMP . . . . . . . . . . . . . . . . . . 132

5.5. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

6. Tecnologias de acceso 135

6.1. Cobertura de Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.1.1. Red de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.1.2. Contexto de Internet y servicios de Banda Ancha en México . . . 138

6.1.3. Banda Ancha . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6.2. Tecnologías de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.2.1. Tecnologías de acceso cableadas . . . . . . . . . . . . . . . . . . 143

6.3. Tecnologías de acceso inalámbricas . . . . . . . . . . . . . . . . . . . . 149

6.3.1. Telefonía celular . . . . . . . . . . . . . . . . . . . . . . . . . . 158

6.4. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

7. Análisis tecno-económico 163

7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.2. Métricas financieras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.2.1. Costo total de propiedad . . . . . . . . . . . . . . . . . . . . . . 164

7.2.2. Retorno de inversión . . . . . . . . . . . . . . . . . . . . . . . . 169

7.2.3. Valor Presente Neto . . . . . . . . . . . . . . . . . . . . . . . . . 173

V

Page 8: Diseño y Arquitectura de Redes Telemáticas

7.3. Análisis tecno-económico . . . . . . . . . . . . . . . . . . . . . . . . . . 175

7.3.1. Análisis de rentabilidad . . . . . . . . . . . . . . . . . . . . . . . 177

7.3.2. Despliegue y operación de la red . . . . . . . . . . . . . . . . . . 185

8. Respuestas a problemas seleccionados 193

VI

Page 9: Diseño y Arquitectura de Redes Telemáticas
Page 10: Diseño y Arquitectura de Redes Telemáticas
Page 11: Diseño y Arquitectura de Redes Telemáticas

Capítulo 1

Metodología de diseño de redes

1.1. Introducción

Es impresionante constatar la gran cantidad de redes que han sido implementadas demanera empírica y reactiva: reaccionando a las demandas inmediatas de los usuarios sintomar el tiempo necesario para hacer una buena planeación de la misma con base en lasnecesidades reales de la empresa.

La mayoría de estas redes están destinadas al fracaso conforme exceden una mínimacomplejidad: no fueron dimensionadas adecuadamente; no se contemplaron con anticipa-ción aspectos fundamentales como la seguridad y la gestión de la red; no fueron previstoslos requerimientos de escalabilidad a mediano plazo; etcétera. Es decir, este tipo de redesno fueron planificadas y por consiguiente las demandas de los usuarios tarde o tempranoterminarán por exceder sus capacidades. Inspirados en las palabras de Dwigth D. Eisen-hower:

“Nunca una batalla se ganó de acuerdo con el plan.... Pero jamás una batallase ganó sin un plan”,

el objetivo principal de esta obra es presentar una metodología que facilite el diseño deredes eficientes. Esta metodología, basada en un diseño descendente, permite planear losrequerimientos de la red a partir de los requerimientos de negocio de las aplicaciones yusuarios de la red.

Lo que se busca es proporcionar un marco operativo para hacer frente a la batallapermanente en la que se encontrará enfrentada la red debido a los factores tan dinámi-cos en los que ésta se verá inmersa (cambio tecnológico, nuevas aplicaciones, escenarioscambiantes de negocio y de usuarios, etc.).

¿Por qué una empresa desea una red?

Prácticamente todas les redes de interés no son triviales y fueron creadas para soportarlas necesidades de una empresa u organización. Antes de presentar formalmente la meto-

Page 12: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

dología propuesta, conviene reconocer algunas razones que pueden motivar el desplieguede la infraestructura de red, como por ejemplo:

satisfacer las necesidades de los clientes;

mejorar la comunicación interna y externa;

reducir el ciclo de diseño - fabricación - introducción al mercado;

incrementar la productividad y reducir los costos de operación;

responder con agilidad a las condiciones cambiantes del mercado.

Es claro que la empresa no busca como objetivo el tener la red más avanzada tecnoló-gicamente hablando, sino que desea alcanzar uno o varios objetivos de negocio específi-cos. Por ello:

El mejor diseño NO es aquel que es tecnológicamente más avanzado, o el que aparecemás elegante y eficiente desde el punto de vista de ingeniería. El mejor diseño es aquelque apoya con efectividad a la consecución de los objetivos de negocio y que, además,hace a la red invisible ante los ojos del usuario final.

Fracasos en proyectos de tecnología de información

Desde 1994, la consultora The Standish Group International ha venido realizando di-versos estudios (conocidos como los reportes CHAOS) sobre la calidad de los proyectosde desarrollo de software en los Estados Unidos. La figura 1.1 presenta cómo han evolu-cionado estos reportes de 1994 a 2009.

Figura 1.1: Resolución de proyectos de desarrollo de software. Fuente: Política digital, conbase en los estudios de The Standish Group

Diseño y Arquitectura de Redes Telemáticas 2

Page 13: Diseño y Arquitectura de Redes Telemáticas

1.2. DISEÑO DESCENDENTE

Aunque la encuesta se orientaba principalmente a proyectos de software, es bastanterepresentativa de lo que ocurre con los proyectos de tecnología de información (TI) engeneral, incluidos los proyectos de infraestructura (redes, migraciones, etcétera).

Generalmente, un proyecto cambiado se excedió en tiempo, en recursos, o no cumpliócon sus especificaciones. Se puede observar que apenas poco más de la cuarta parte de losproyectos de TI cubre con sus expectativas iniciales.

Otra encuesta indica que 53 % de los proyectos de tecnología en realizados en el ReinoUnido en 1999 costaron en promedio 189 % más de lo originalmente estipulado.

La figura 1.2 presenta algunas de las principales causas que llevan a la anulación ocambio de proyectos, de acuerdo a lo reportado por las empresas en el estudio CHAOS de1994. Estudios subsecuentes reflejan resultados similares.

Figura 1.2: Principales razones por las que un proyecto fue anulado o modificado. Fuente:The Standish Group, 1994

Como puede observarse, casi el 13 % de los proyectos de TI falla porque los requeri-mientos no fueron suficientes. Esto no necesariamente significa que el cliente o el usuariono los haya proporcionado. En muchas ocasiones, el responsable del proyecto no lossolicitó, no los entendió, o no los interpretó adecuadamente.

Todos los elementos identificados en la figura 1.2 han ocurrido y ocurren regular-mente en proyectos de diseño y construcción de redes y sus servicios correspondientes.Todos ellos deben ser considerados riesgos potenciales de cualquier proyecto. Sortear losescollos que imponen estos riesgos requiere de orden, método y disciplina.

1.2. Diseño descendente

La figura 1.3 presenta el método de diseño llamado descendente, en el cual se estruc-tura el contenido de estas notas.

El método inicia con un esfuerzo enfocado a comprender los objetivos de negocio dela organización que necesita la red, y de ahí a comprender los objetivos específicos que sedeben fijar en términos de calidad y variedad de servicios a ofrecer. Con estos elementos,

Diseño y Arquitectura de Redes Telemáticas 3

Page 14: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Figura 1.3: El método de diseño descendente

se podrán identificar las aplicaciones capaces de proporcionar los servicios necesarios ylas implicaciones e impacto que dichas aplicaciones tendrán sobre la red que las soporta.

La identificación de las aplicaciones y sus características permite establecer los reque-rimientos con los que se realiza el diseño de la red, partiendo de los servicios que debeofrecer a los usuarios (capas superiores), y aumentando el nivel de detalle hasta llegar aldiseño físico con la selección de tecnologías y equipos específicos.

Como todo proceso de diseño, este método es iterativo y es consistente con el ciclo devida de un proyecto de desarrollo de red, el cual se muestra en la figura 1.4.

Figura 1.4: El ciclo de vida de un proyecto de red

Si bien estas notas se centran en las dos primeras fases del ciclo de vida, y principal-mente en la de diseño, las fases no son independientes. Por ejemplo, en el capítulo 4 semostrará que durante el diseño lógico de la red se definen políticas de administración ymonitoreo con las que se validará la red de producción.

El proceso es continuo. Una vez que los parámetros monitoreados indican que la redes insuficiente, o cuando los requerimientos cambian, se reinicia el ciclo.

Diseño y Arquitectura de Redes Telemáticas 4

Page 15: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

1.3. Microsoft Solutions Framework

El diseño descendente es la metodología propuesta para realizar un proyecto de diseñode redes. También es necesario identificar una estrategia, una forma de trabajo que permitacontrolar de forma adecuada el desarrollo del proyecto. La que se presentará brevementeen este capítulo es la conocida como los Principios de Desarrollo de Infraestructura delMarco de Soluciones de Microsoft (Microsoft Solutions Framework, MSF).

Microsoft Solutions Framework es un conjunto de principios y procesos que resumelas “mejores prácticas” en proyectos de TI. Es una disciplina de trabajo, no una meto-dología, que ayuda a estructurar el proceso, el equipo de trabajo y la administración deriesgos en proyectos de alta tecnología. Los Principios de Desarrollo de Infraestructurason el componente de MSF que se enfoca a proyectos de infraestructura de TI, más que aproyectos de desarrollo de software.

Para MSF, los cuatro componentes principales de un proyecto de diseño de redes semuestran en la figura 1.5 y son:

Figura 1.5: Componentes de MSF para el desarrollo de un proyecto de TI

El modelo de equipo. Explica cuáles son los principales roles y funciones que deben sercubiertos en el proceso de organizar y estructurar nuestro equipo de trabajo.

El modelo de proceso. Explica cuáles son las diferentes fases del proyecto y sobre quéaspectos debe hacerse énfasis en cada proyecto.

El diseño de red. Señala, desde un punto de vista técnico, cuáles son los pasos a seguiry qué variables deben ser consideradas en el proceso de análisis y diseño de la red.

Diseño y Arquitectura de Redes Telemáticas 5

Page 16: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

El análisis de riesgos. Explica cómo se pueden detectar y evaluar los diferentes tipos deriesgo que afectan al proyecto y el tratamiento que se les debe dar con objeto deevitar que se materialicen o, si es imposible evitarlos, cómo aminorar sus efectos lomás posible.

Podría decirse que el modelo de diseño descendente explica los pasos a seguir paracompletar el diseño de una red mientras que los Principios de Desarrollo de Infraestruc-tura explican cómo organizar los otros tres componentes y cómo mantener balanceado eltriángulo de variables a gestionar:

Recursos (humanos y materiales) para realizar el proyecto;

funciones que habrá de ofrecer la red y sistemas asociados;

calendario que deberá cumplirse para llevar el proyecto al éxito.

La base de ese triángulo es la calidad. Estos tres componentes deben estar bien apuntala-dos con el fin de mantener equilibrado el triángulo de calidad.

MSF reconoce que en los proyectos tecnológicos actuales existe una gran cantidad deriesgos propios de la naturaleza cambiante de las mismas tecnologías, así como de suutilización en condiciones diferentes a aquellas para las que fueron desarrolladas.

MSF hace énfasis en identificar y comprender los riesgos que amenazan al proyectopara poder trabajar en su control y mitigación y finalmente busca facilitar la divisiónde la visión en porciones o versiones con alcances intermedios y realistas.

1.3.1. Modelo de proceso

Figura 1.6: Las cuatro fases del modelo de proceso de MSF para el desarrollo de infraes-tructura

El modelo de proceso marca cuatro fases para todo proyecto: visión, planeación, desa-rrollo y despliegue. Cada una de ellas tiene un punto claro de cierre que va acompañado

Diseño y Arquitectura de Redes Telemáticas 6

Page 17: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

con un entregable específico. Este punto de cierre se representa por el diamante azul en lafigura 1.6. Es muy importante que haya un acuerdo claro, y preferentemente firmado, portodos los jugadores al final de cada fase.

Visión/Alcance. La primera fase busca establecer una Visión conjunta del proyecto, de-terminar el alcance del mismo y establecer en forma general las condiciones ini-ciales de que se dispone para el proyecto. Así mismo es importante entender loselementos básicos y objetivos de negocio generales de la organización que necesitala red. La palabra clave en esta fase es Escuchar.

Planeación. La segunda fase busca caracterizar todos los aspectos importantes de la redy/o infraestructura ya existente, transformar los objetivos y alcances de negocio ex-presados en la fase anterior a requerimientos técnicos que habrán de ser cumplidospor el diseño que se elaborará en esta. La palabra clave en esta fase es Proponer.

Desarrollo. La tercera fase busca evaluar y validar el diseño propuesto, evaluar las nuevasy diferentes tecnologías propuestas para integrar la solución y proponer los ajustesnecesarios al diseño y planes propuestos en la fase anterior. Las pruebas se realizanprimero a nivel individual para cada nueva tecnología, y posteriormente se reali-zan pruebas de integración y pilotos. Esta fase concluye con la liberación de lasolución/diseño propuestos y las palabras clave son Analizar y Probar.

Despliegue. La última fase es propiamente el despliegue e implementación de la soluciónde acuerdo con el diseño propuesto. Los elementos centrales a considerar en estaetapa son la logística y la comunicación con el cliente. La palabra clave para estafase es Actuar.

Para MSF es fundamental el concepto de desarrollo por versiones mostrado en la fi-gura 1.7. Como se verá más adelante, para una primera versión se definen algunas delas especificaciones más importantes del proyecto con las cuales se realiza una primeraiteración en el modelo de proceso.

Para una nueva iteración se incorporan las especificaciones que habían quedado fuerajunto con las solicitudes adicionales del cliente y de los usuarios que se han ido recabando.Estos requerimientos se evalúan a la luz del triángulo de recursos y calidad para elegirlos requerimientos con los que se realizará la nueva iteración, dejando los demás paraversiones futuras.

El diseño por versiones es conveniente para el desarrollador con el fin de minimizarlos riesgos y mantener el control sobre el proyecto. También es conveniente para el clientepues en proyectos de TI, es común que el usuario identifique con mayor claridad lo querealmente desea y necesita conforme empieza trabajando con el nuevo producto.

Fase I: Visión y alcance. (Escuchar)

Es conveniente recordar que ninguna empresa diseña y construye redes porque deseatener la tecnología más novedosa. Las organizaciones suelen, o al menos debieran, tener

Diseño y Arquitectura de Redes Telemáticas 7

Page 18: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Figura 1.7: En MSF el proyecto va creciendo en funcionalidad en distintas versiones

Figura 1.8: La fase de visión/alcance de MSF y sus entregables

Diseño y Arquitectura de Redes Telemáticas 8

Page 19: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

objetivos claros y específicos sobre lo que quieren lograr o facilitar con la construcción deuna red de comunicaciones, como de cualquier otro proyecto de tecnología de informa-ción. Lo que las empresas buscan con la red es alcanzar uno o varios objetivos de negocio.El proyecto tendrá éxito en la medida en la que esto se comprenda.

Lo primero que debe conseguirse en esta fase, es el establecimiento de una Visión únicade lo que se desea lograr. La Visión es la imagen que se forman y comparten todos losinvolucrados sobre lo que el proyecto les permitirá hacer cuando esté terminado.

Una visión puede ser demasiado extensa y concebida en el largo plazo, en cuyo caso esconveniente descomponerla en partes más pequeñas llamadas versiones, que permitirántener un acercamiento gradual y ordenado hacia la visión final. Es importante explicardesde el principio el concepto de desarrollo por versiones a clientes y usuarios, de ma-nera que se puedan asignar prioridades a las especificaciones y se eviten expectativas norealistas en las primeras versiones del proyecto.

Por ello es necesario definir el alcance inmediato del proyecto, es decir, hasta dóndellegará la versión actual en la que se estará trabajando, en su camino a la consecución dela visión. La mejor manera de lograr esto es definiendo un número limitado de objetivosclaros y concretos, como se verá más adelante.

De la figura 1.2 se infiere que el no definir los objetivos con precisión, puede tenerun efecto devastador para el proyecto. Por ello, es fundamental escuchar y entender cla-ramente las necesidades de los usuarios y de sus aplicaciones. Es importante tambiénidentificar lo que suele llamarse la cultura tecnológica reinante dentro de la empresa (tec-nologías dominantes, experiencia de los usuarios y administradores, acuerdos de negociopredefinidos) y su cultura social (estructura jerárquica, grupos dominantes, apertura decomunicación, flexibilidad al cambio, etc.).

La Visión

La visión es primordialmente un documento de negocios, escrito para una audienciade negocios, por lo que se debe evitar utilizar un lenguaje demasiado técnico y, sobretodo, pensar en tecnologías específicas en esta fase.

Si bien es cierto que un proyecto de diseño de red es eminentemente tecnológico y queel impacto sobre el negocio es principalmente indirecto, es extremadamente importanteque la visión y los objetivos estén especificados en un lenguaje que pueda ser entendidopor el cliente, y que este se sienta identificado tanto con la visión como con los objetivos.

Es fundamental establecer una visión conjunta, que sea enunciada por el cliente, y quelos integrantes del proyecto entiendan y compartan. Una visión que entienda que unared está al servicio del negocio. Nunca al revés.

La visión es la traducción a palabras de cómo será el ambiente ideal que habrá detraer la solución. El tener una visión y objetivos compartidos proporciona una serie debeneficios a todos los involucrados, entre los que se pueden destacar:

Diseño y Arquitectura de Redes Telemáticas 9

Page 20: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

compromiso de todo el equipo para lograr los objetivos y así avanzar hacia la visión;

ayuda a todos los miembros del equipo a dirigir sus esfuerzos hacia el mismo obje-tivo;

evita posibles conflictos futuros;

ayuda al equipo a identificar y aplicar los recursos de manera apropiada;

le da identidad al equipo;

motiva al equipo.

El alcance

Una vez obtenida la visión, se procede a establecer el alcance de ESTA versión pueses probable que la visión sea demasiado amplia para poder ser lograda de una sola vez.

Definir los alcances para la versión particular que se está especificando, permite ma-pear la visión contra la realidad actual. En este mapeo se debe tomar en cuenta aquelloque el cliente considera indispensable para el éxito del proyecto. Esto permite acotar laversión actual a un número limitado de objetivos muy concretos y desplazar lo no esencialhacia versiones futuras.

Para poder lograr esto es fundamental haber definido con el cliente una visión y ob-jetivos compartidos. Sin este compromiso, el cliente bien podría tomar la posición de“quererlo todo, quererlo bien, quererlo ahora”:

sin retardos

sin costo para el usuario

sin restricciones de protocolos nide funcionalidad

sin restricciones físicas ni lógicas

sin errores

acceso universal

interconectividad entre redes

facilidades de difusión

Al recibir una lista como la anterior, es necesario cuestionar si el cliente realmentedepende de esos requerimientos. Como se verá más adelante, este tipo de criterios puedeentrar en serios conflictos con otros requerimientos de la red, lo cual puede comprometertodo el proyecto. Pero además, si no se han definido los alcances de manera conjunta, lomás probable es que los requerimientos del usuario sean vagos, incompletos, y, además,variarán durante el tiempo de vida del proyecto.

La imagen y la comprensión común sobre lo que se va a hacer y los objetivos delproyecto tienen que estar totalmente claros, como también lo deben estar para el usuariolas implicaciones de las decisiones que se toman en términos de restricciones futuras,costos y riesgos. Si hay algo que el cliente/usuario solicita y se considera que no se puedeo que tiene implicaciones graves en términos de costo, tiempos, etc. este es el mejormomento para decirlo.

Diseño y Arquitectura de Redes Telemáticas 10

Page 21: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

Be SMART

Los objetivos de negocio y los criterios de éxito (que pueden ser los mismos), tienenque ser claros, acotados y limitados a no más de cinco, y preferentemente menos de tres.Pueden ser técnicos y de negocio, de preferencia una combinación de ambos.

Vaguedades en la definición de cualquier objetivo puede conducir a no cubrir las ex-pectativas del cliente, a no tener claro cuándo se ha cumplido (y por consiguiente a alargarel proyecto indefinidamente), y en general a situaciones que redundarán en la inconfor-midad y consiguiente insatisfacción del cliente.

Diseño y Arquitectura de Redes Telemáticas 11

Page 22: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Al definir los objetivos de esta versión del proyecto, es muy importante que cumplancon los criterios “SMART”1:

Specific.- Deben establecer claramente lo que se debe realizar (“qué, quién, cuándo, có-mo, por qué”).

Mesurable.- Deben ser determinados en términos cuantitativos, que puedan medirse paraestablecer si se está cumpliendo el objetivo.

Achievable.- Deben ser realizables en esta versión del producto o en esta iteración delproyecto considerando las capacidades y restricciones impuestas.

Realistic.- Debe tratarse de objetivos en los que se puede y se desea trabajar.

Time-oriented.- Deben estar claramente especificados en un horizonte de tiempo realista.

En muchas ocasiones es el cliente mismo quien no está interesado o dispuesto a es-tablecer estos objetivos SMART. Las razones para esto pueden ser variadas, pero radicantípicamente en el hecho de que el cliente mismo no tiene claro qué es lo que quiere o puedepedir. Es altamente recomendable trabajar con él para llegar a una definición precisa.

La opción aquí es rechazar el proyecto, actitud por demás profesional y recomendablesi la indefinición es extrema, o correr el riesgo de la insatisfacción final o de pérdidaseconómicas por no haber podido dimensionarlo apropiadamente.

Culminando la fase de visión/alcance

El entregable en esta etapa es un documento muy completo de visión y alcance, elcual contiene típicamente:

visión del negocio;

objetivos de negocio y criterios de éxito definidos con características SMART;

otra información de negocio;

estructura corporativa a nivel macro o medio, según sea necesario;

distribución geográfica de oficinas, personal y departamentos. Toda aquella infor-mación que permita posteriormente evaluar las necesidades de hoy y las posiblesnecesidades en términos de escalabilidad: ¿Cuánto espera el cliente crecer en elfuturo y en dónde?

1Para algunos investigadores, las siglas pueden tener significados ligeramente distintos, por ejemplo:“R”elevantes y “T”angibles.

Diseño y Arquitectura de Redes Telemáticas 12

Page 23: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

identificar tipos de usuario, puede ser por departamento por función, rango, etc.En la siguiente fase se buscará entender cuáles son las necesidades de cada tipo deusuario;

presupuesto;

políticas y estándares corporativos relevantes;

información técnica;

requerimientos de seguridad.

El documento de visión puede incluir la documentación concerniente a la red actual(si existe) y las minutas de las reuniones realizadas durante esta fase. Para poder integrareste documento de la mejor manera posible, es necesario recabar bastante información(la palabra clave aquí es escuchar). Un ejemplo del tipo de información a colectar en estaetapa es:

uso que dará el usuario a la red,sin tener en cuenta cómo estará in-ternamente implementada;

tipo y número de usuarios y apli-caciones haciendo uso de la red;

caracterización de aplicaciones;

requerimientos geográficos;

prioridades por aplicación o tipode tráfico;

interconexión a otras redes y a laInternet;

expectativas de tiempo de accesoy respuesta;

requerimientos de disponibilidady confiabilidad;

requerimientos de seguridad;

holgura y capacidad para deman-da futura de servicio;

tarificación;

restricciones presupuestales.

Este documento permitirá iniciar con un diseño conceptual de la red. También permi-tirá identificar el orden en el que se responderá a los requerimientos de negocio, ayudará acimentar el plan maestro y calendario de trabajo que serán definidos en la etapa siguiente,y dará una estimación de los recursos humanos, económicos y tecnológicos necesariospara completar el proyecto.

Un buen documento para cerrar esta etapa deja sentadas las bases para traducir lasnecesidades y objetivos de negocios en él expresadas, a requerimientos técnicos2. Porotra parte, este documento debe reflejar claramente que se ha llegado a un acuerdo entretodos los involucrados acerca de los siguientes puntos:

los objetivos de negocio;

la visión del proyecto y el alcance de esta versión;

2En el capítulo siguiente serán definidos con precisión algunos requerimientos técnicos.

Diseño y Arquitectura de Redes Telemáticas 13

Page 24: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

el diseño conceptual de la solución propuesta;

los entregables identificados;

una idea general del orden de recursos necesarios;

un plan para la siguiente fase;

un documento de análisis de riesgos.

Fase II: Planeación. (Proponer)

Figura 1.9: La fase de planeación de MSF y sus entregables

En la primera fase del proyecto se enfatizó en comprender las necesidades y objetivosde negocio. Al hacerlo se fue aclarando el tipo de aplicaciones y servicios que se utilizarány algunas de las restricciones impuestas por ellos, ya sea porque existan y se manifiestenantes del inicio del proyecto, o porque vayan a aparecer durante o después del mismo.

En esta fase el resto de las restricciones impuestas por las aplicaciones y serviciosdeberán conocerse. Contando con esta información, se podrá avanzar en el diseño delas cuatro capas inferiores de la red. Se está aplicando el método descendente de diseñode redes al comenzar por las capas superiores (necesidades de negocio, aplicaciones yrequerimientos) y con ello la funcionalidad y especificaciones necesarias para las capasmás bajas se va aclarando. Es importante realizar un trabajo detallado y exhaustivo paracomprender las implicaciones y restricciones impuestas por las necesidades y objetivosde negocio, así como las implicaciones y restricciones impuestas por las aplicaciones quese ejecutarán.

Sin embargo, siempre existirá la posibilidad de que las aplicaciones se comportende una manera diferente a lo esperado, por ejemplo, porque el nivel de carga es muydistinto a lo planeado, por cambios de versión, por especificaciones inexactas por partedel proveedor, etc. Por ello, se debe realizar un buen análisis de riesgos, para poder tomardecisiones apropiadas en lo que se refiere a garantizar calidad de servicio en las etapasiniciales, o inclusive posteriores al inicio de la operación del proyecto.

Diseño y Arquitectura de Redes Telemáticas 14

Page 25: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

Los entregables de esta fase están constituidos por borradores de los documentosindividuales, pues el diseño no puede validarse sino hasta la siguiente fase, en la que serealiza una serie de pruebas de concepto. Es posible que esas pruebas generen cambios enel diseño propuesto. Una vez concluidas las pruebas necesarias en la Fase III, se procedea fijar el diseño y con ello el plan y el calendario maestros.

El proceso de diseño

El proceso de diseño es iterativo y pasa por tres etapas, cada una agregando mayornivel de detalle que la anterior.

Diseño conceptual. El diseño conceptual ocurre durante la fase de Visión/Alcance y con-siste en listar y entender los diferentes elementos de negocio que intervendrán enla solución final. Es decir, considerar y entender qué factores de organización dela compañía, distribución geográfica y características propias del negocio tendránun impacto en el diseño de la red. Una vez conocidos estos elementos, se procedea elaborar un borrador o diseño inicial que se habrá de enfocar en representar lafuncionalidad y distribución general requerida, incorporando poco o ningún detallede tipo técnico. Este es un diseño que fácilmente podrán comprender las personasde áreas de negocios.

Diseño lógico. Las siguientes etapas ocurren durante la fase de Planeación. Se realizaun primer plano técnico de la solución, sin incluir dimensionamientos, modelos niconfiguraciones específicas.

Diseño físico. Una vez que el diseño lógico está completo y se considera que cumple conlos requisitos establecidos, se incrementa el nivel de detalle, agregando modelos,configuraciones y demás especificaciones, llegando con esto al máximo nivel dedetalle posible en papel.

Durante las etapas de diseño se habrán de ir integrando las tres componentes funda-mentales del documento que termina esta etapa:

Especificación funcional. Indica el qué debe hacerse.

Plan maestro. Indica el cómo y con qué recursos la solución será desarrollada, evaluaday desplegada.

Calendario maestro. Indica el cuándo se harán dichos desarrollos, evaluaciones y des-pliegues.

Este documento debe ser considerado como un contrato entre las personas que desa-rrollan el proyecto, el cliente y usuarios. Es vital que haya un acuerdo claro en lo quese refiere a la funcionalidad esperada en esta versión del producto por todas las partes.

Diseño y Arquitectura de Redes Telemáticas 15

Page 26: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Especificación Funcional

La especificación funcional es el documento de diseño propiamente, en el cual seincluyen los objetivos y requerimientos de negocio como fueron expresados en el docu-mento de Visión/Alcance. De hecho, el documento de Visión/Alcance sirve por lo generalcomo introducción a este documento.

Para poder hacer una especificación funcional adecuada, es necesario recabar el má-ximo de información posible, por ejemplo:

documento de visión/alcance;

caracterización de la red (topología de red, flujos de información, características deltráfico);

diseño de red: conceptual, lógico (requerimientos de seguridad, administración,QoS, etc.), y físico (selección de tecnologías, estándares, dispositivos, capacidades,protocolos, etcétera).

La especificación funcional deberá proporcionar una indicación clara y concisa sobrecómo se cumplirá con los requerimientos de diseño y cómo se responderá a las necesida-des de negocio. Si hay una limitante grave, hay que sacarla a la luz cuanto antes. Tambiéndebe quedar claro de qué manera la solución propuesta se integra con los estándares ypolíticas corporativas.

Durante la caracterización de la red, se obtendrá una definición completa de los per-files de usuario y sus necesidades: se deberán detallar los “tipos"de usuario definidos porlas aplicaciones que utilizan; ¿Dónde se encuentran las aplicaciones y servicios a los quetendrán acceso?; ¿Quién necesita acceso remoto y desde dónde?

También se deberán identificar los requerimientos técnicos y las limitaciones de lasconfiguraciones resultantes, y cómo responderá el diseño a los mismos. Se deberán es-pecificar los requerimientos mínimos de hardware, software y de comunicaciones para lasolución propuesta.

Desde la especificación funcional se define la estrategia de administración y monito-reo: se seleccionan los métodos para recolección periódica de información; se identifican“signos vitales” de la red; se empiezan a documentar los procesos o pasos a seguir encaso de detectar diversas fallas en la red; se especifican los métodos de escalamiento, losreportes de fallas a proveedores de productos y servicios; se delinea la implementación deuna mesa de ayuda, si ésta no existe.

Los siguientes son algunos de los riesgos más importantes que deben evitarse al do-cumentar la especificación funcional:

falta de detalle que impida hacer las pruebas y/o despliegue apropiados;

diseño demasiado costoso para ser implementado;

demasiada información innecesaria;

Diseño y Arquitectura de Redes Telemáticas 16

Page 27: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

congelar el diseño antes de tener la información apropiada;

especificación incompleta al momento de iniciar los trabajos finales.

Plan maestro

El plan maestro enuncia la secuencia de tareas y actividades que habrán de realizarsee indica quién es el responsable de cada una y quiénes participan. Esto es muy importanteya que de otra manera se dejará abierta la puerta a todo tipo de riesgos y malentendidos.

En el borrador del plan maestro se detalla la estrategia de pruebas y el plan piloto asícomo el plan y la estrategia de despliegue. Esta información permitirá dar una estimaciónde los recursos humanos, económicos y tecnológicos necesarios para completar el pro-yecto. También deberá incluir un plan de capacitación a personal técnico y a usuarios, asícomo una estrategia de comunicación entre los participantes. Finalmente, se debe especi-ficar el presupuesto disponible junto con el plan de flujo financiero y de adquisiciones.

Calendario maestro

El calendario maestro indica las fechas en las que se realizarán las diferentes acti-vidades. En él debe especificarse la secuencia y duración de todas las actividades antesseñaladas. Es común y recomendable que se trate de diseñar un calendario maestro quepermita incluir el llamado tiempo buffer para manejar la incertidumbre. Bajo este esque-ma, se consideran dos fechas objetivo: una interna (fecha real) y otra externa, para elcliente. Como se observa en la figura 1.10, la diferencia entre la fecha objetivo interna yla externa es el tiempo buffer.

Figura 1.10: Buffer interno para manejar la incertidumbre

Esta es una práctica sana, siempre y cuando no se abuse de la misma. Como los pro-yectos de TI involucran una gran cantidad de variables que pueden modificar tiempo yresultados, es conveniente que el administrador del proyecto mantenga tiempos de reser-va que puedan ser utilizados para cubrir los imprevistos. Dicho margen o buffer está bajosu control y se utiliza para emergencias.

Es muy importante subrayar que el análisis, el diseño y las pruebas deben realizarseen forma completa, de tal manera que la especificación funcional, el plan maestro y elcalendario maestro se basen en información concreta y lo más realista posible, en hechos.Los buffers de tiempo mencionados aquí serán insuficientes si se utilizan como margende error para un proyecto mal diseñado.

Diseño y Arquitectura de Redes Telemáticas 17

Page 28: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Culminando la fase de planeación

Para finalizar la fase de planeación es necesario que el diseño esté concluido en sutotalidad. Se debe contar con un acuerdo grupal sobre los elementos desarrollados durantela planeación: especificación funcional, plan maestro, calendario maestro y una nuevaiteración del análisis de riesgos.

Fase III: Desarrollo. (Analizar y probar)

Figura 1.11: La fase de desarrollo de MSF y sus entregables

El proceso de construir e integrar porciones de la solución para convertir la especifi-cación en una solución completa es lo que se conoce como el desarrollo de la infraestruc-tura. En esta fase se busca evaluar y validar el diseño, empezando por evaluar las nuevastecnologías propuestas para integrar la solución y, eventualmente, proponer los ajustesnecesarios al diseño original.

Las pruebas se realizan de manera cíclica e incremental: pasando por las etapas dedesarrollo, evaluación y validación contra los criterios de aceptación previamente defini-dos. Este ciclo se aplica a nivel individual, para cada nueva tecnología y posteriormente,para las pruebas de integración e implementación de los pilotos.

Validación de la tecnología

Conforme se están validando las nuevas tecnologías seleccionadas, en esta etapa sevan creando manuales de instalación y operación y otros documentos de apoyo (capa-citación, bitácoras, etc.). Por lo tanto, la validación de tecnologías incluye realizar lasactividades siguientes:

analizar los criterios de selección de tecnologías, sobre todo si éstas son nuevas;

instalar y configurar manualmente en condiciones ideales;

documentar los pasos a seguir para que opere correctamente;

Diseño y Arquitectura de Redes Telemáticas 18

Page 29: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

comenzar a identificar y documentar pendientes y riesgos tecnológicos;

actualizar el calendario de trabajo con base en los riesgos detectados.

El desarrollar una campaña de pruebas es una tarea compleja que puede demandarmuchos recursos (tiempo, equipo, personal) y que puede no arrojar los resultados espe-rados si no se hace correctamente. Por ello, es muy importante que se dedique el tiemponecesario para diseñar las pruebas en función de los objetivos que se persiguen. Algunosde los objetivos que deben quedar claros en esta etapa son:

sacar a la luz todos los puntos que el equipo debe resolver;

validar lo que se tiene contra la especificación funcional;

realizar pruebas de regresión (cuando la solución falla o hace fallar algo en el am-biente de operación);

determinar si la solución requiere componentes adicionales (controladores actuali-zados, librerías dinámicas, versiones específicas de ambientes operativos, etcétera).

Es fundamental poder separar el ambiente de pruebas del de producción en las pri-meras etapas del proceso de evaluación: errores o problemas detectados con la soluciónevaluada no deben afectar a la red de producción. Esta etapa de la fase de desarrollo esconocida como de pruebas de preproducción y sus objetivos son los siguientes:

probar tanto de la solución como sea posible, antes de integrar el piloto;

evaluar resultados contra los objetivos y criterios de éxito;

completar guías de instalación (checklists) y desarrollar procedimientos automati-zados para ello (bitácoras, scripts, etcétera);

desarrollar el material de capacitación completo;

resolver pendientes y problemas de soporte.

El automatizar en la medida de lo posible las tareas de instalación y validación essumamente aconsejable, pues ello contribuye a disminuir tiempos y esfuerzo en la etapade despliegue, reduce drásticamente los retardos debidos a errores humanos, proporcionalineamientos para diagnosticar y corregir problemas, y ayuda en la definición de procedi-mientos de respaldo y recuperación de desastres.

Otros entregables que deben generarse al realizar las validaciones en esta etapa, es-tán orientados al personal encargado de la operación de la red en producción e incluyendocumentos que abarquen temas como:

requerimientos especiales para mantenimiento de clientes, servidores y dispositivosde red;

Diseño y Arquitectura de Redes Telemáticas 19

Page 30: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

lineamientos para recuperación de desastres y reinstalación;

monitoreo de fallas y parámetros de desempeño en operación normal;

soporte y solución de problemas;

procedimientos de respaldo.

Prueba de concepto

Una vez que las herramientas individuales han sido evaluadas, la prueba de conceptoconsiste en validar la solución completa inmediatamente antes de integrarla a la red deproducción. Específicamente, debe validarse que se cumple completamente con los re-querimientos de diseño. Esto se hace generalmente junto con el cliente y/o personal queva a operar la red de manera cotidiana, y basándose en el plan de pruebas definido conanterioridad.

Conforme se va integrando la prueba de concepto, se seguirán documentando los pro-cesos de implementación, se desarrollarán mecanismos de automatización para la instala-ción y despliegue, se verificarán y complementarán las guías de instalación y se desarro-llarán manuales de operación.

Prueba piloto

El piloto es el momento en que se evalúa la solución dentro del ambiente de produc-ción. Es una actividad muy importante pues valida la solución completa y su integracióncon los sistemas ya implementados. Además, se debe considerar al piloto como un proce-so de entrenamiento hacia la fase de despliegue que permite verificar que todo lo que seha hecho durante la fase de desarrollo está correcto y completo:

procesos de instalación y automatización;

identificar pendientes y darles seguimiento;

realizar y probar planes de recuperación;

checklist de preparación del sitio;

materiales de capacitación para el usuario y para los administradores de la red.

Implementar y activar el piloto puede tener serias consecuencias en la operación delos sistemas y dispositivos en la red de producción, por lo que debe haber una muy bue-na planeación, manteniendo una estrecha comunicación con todos los involucrados. Porejemplo, se deberá:

Diseño y Arquitectura de Redes Telemáticas 20

Page 31: Diseño y Arquitectura de Redes Telemáticas

1.3. MICROSOFT SOLUTIONS FRAMEWORK

asegurar que se tiene el soporte técnico y los recursos necesarios para instalar yactivar el piloto (identificación y acceso a los locales donde se llevará a cabo lainstalación; disponibilidad de espacio, de energía eléctrica, de direcciones de red,de posibles contraseñas para acceder y configurar equipo, etcétera);

identificar a usuarios del piloto, comunicarse con ellos y asegurar que existe unproceso de retroalimentación por su parte;

encontrar horarios fuera y dentro de horas laborales para llevar a cabo distintos tiposde evaluación (desempeño, interoperabilidad, estrés, etcétera);

prevenir a los usuarios de posibles degradaciones en la calidad de servicio durantela fase de evaluación.

Culminando la fase de desarrollo

Al terminar esta fase ya no puede haber cambios en el diseño. Debe existir un acuerdosobre las tecnologías empleadas, el plan y documentación para apoyar la capacitaciónde usuarios y administradores y sobre las actualizaciones al plan maestro y al calendariomaestro del proyecto.

Los entregables de esta fase son todos los documentos desarrollados a lo largo de lasevaluaciones: material de capacitación, estrategias para el proceso de despliegue, proce-dimientos automatizados de instalación, checklists para configuración e instalación, guíaspara el personal de operaciones; etcétera.

Fase IV: Despliegue. (Actuar)

Figura 1.12: La fase de despliegue de MSF y sus entregables

En la última fase se lleva a cabo el despliegue e implementación de la solución deacuerdo con el diseño propuesto y se cierra el proyecto. Básicamente existen dos estrate-gias: despliegue en serie, en donde se parte implementando el núcleo de la red y se vanagregando sitios de acuerdo a su orden de importancia, y despliegue en paralelo en el quetodos los sitios se van implementando más o menos al mismo tiempo.

Diseño y Arquitectura de Redes Telemáticas 21

Page 32: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Con la estrategia de despliegue en serie se reduce el riesgo del proyecto, la necesidadde personal especializado y la erogación de recursos. Sin embargo, aumenta el tiempo deliberación de la solución completa. La decisión dependerá, en realidad, de las caracterís-ticas del proyecto y de los recursos disponibles.

En cualquier caso, el despliegue de un sitio pasa básicamente por las mismas etapas,que son:

Preparación del sitio. Se valida información obtenida a lo largo del proyecto, se realizael plan de despliegue para el sitio y se notifica a los usuarios sobre el calendario ylas perturbaciones posibles que sufrirán.

Instalación de la solución. Al igual que en la etapa de desarrollo, se debe tener una es-trecha comunicación con los administradores de la red para garantizar que se dis-pone de los recursos físicos y lógicos para llevar a cabo la instalación.

Capacitación del personal. En función de los objetivos y alcances del proyecto, el plande capacitación puede incluir a los administradores y operadores de la red, a losencargados de la mesa de ayuda, y a los usuarios finales.

Estabilización. Es importante que el sistema quede estabilizado cuando aún está presen-te el personal responsable del diseño y se está migrando la gestión del mismo alpersonal de operaciones. Esta transición debería incluir la activación del sistema dereportes (mesa de ayuda), la creación de bitácoras de fallas, estrategia de solucióny análisis de tendencias que permita la creación de una base de conocimiento. Laetapa de estabilización termina con la aceptación final.

Culminando la fase de despliegue

Una vez que se ha liberado y estabilizado el proyecto, se obtendrá la aceptación finalpor parte del cliente, pero para el equipo de trabajo el proyecto no ha terminado puesdebe hacerse una revisión de las experiencias adquiridas a lo largo del desarrollo delproyecto que permita plasmar en un reporte final las consideraciones a tomar en cuentapara proyectos futuros similares al recién liberado.

1.4. Análisis de riesgos

El análisis de riesgos es una actividad fundamental en toda metodología formal deadministración de proyectos. Para MSF, se trata de uno de los cuatro componentes funda-mentales y constituye una actividad continua a todo lo largo del modelo de proceso. Tienepor objetivo identificar las fuentes principales de riesgos, sus implicaciones y la forma enla que estos pueden ser controlados.

Los riesgos son peligros que se presentan y amenazan el éxito del proyecto; su identifi-cación es algo completamente deseable y su solución y mitigación es responsabilidaddel equipo entero.

Diseño y Arquitectura de Redes Telemáticas 22

Page 33: Diseño y Arquitectura de Redes Telemáticas

1.4. ANÁLISIS DE RIESGOS

Al identificar el riesgo global del proyecto se busca determinar cuáles son las impli-caciones si el proyecto falla completamente o si no corresponde a las expectativas. Hayque empezar por establecer si el proyecto es crítico para la operación de la empresa.

También es importante conocer el nivel de visibilidad y repercusión del proyecto: ¿Eléxito (o fracaso) del proyecto es visible por otras áreas? ¿Por las áreas directivas? ¿Porlos clientes? La respuesta a estas preguntas puede influir de manera importante en loscriterios de diseño a emplear.

Los riesgos se pueden originar de las más diversas fuentes, entre las más evidentes sepueden citar:

definición imprecisa de visión, objetivos y restricciones;

nivel de motivación en la decisión o dirección de la organización;

perfil y compromiso de clientes o usuarios;

presupuesto, costo, calendario y recursos humanos;

características del proyecto;

ambiente y proceso de desarrollo e implementación;

ambiente de operaciones;

nuevas tecnologías.

Las restricciones del proyecto son riesgos naturales que deben ser identificados. Lasiguiente lista muestra algunos aspectos que deben ser típicamente tomados en cuentadurante la fase de análisis de riesgos:

restricciones presupuestales y gestión del mismo;

adquisición de equipo, software, licencias, etcétera;

contratación / capacitación de personal;

agenda: ¿Existen agendas ocultas? ¿El proyecto ya se ha retrasado? ¿Se está reto-mando un proyecto que fue abandonado por otro grupo? ¿Por qué?;

políticas y estrategias;

existencia de grupos de poder: tomadores de decisiones vs. seguidores;

implicaciones del proyecto: ¿A quién beneficia el éxito del proyecto? ¿Quién loapoya? ¿Provoca despidos de personal? ¿Cambio de funciones y de roles?;

alianzas y/o políticas de adquisición de equipo, estándares internos, etcétera;

aspectos personales de todos los involucrados;

actitud de la empresa: innovadora o conservadora tecnológicamente.

Diseño y Arquitectura de Redes Telemáticas 23

Page 34: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

1.4.1. Manejo de Riesgos

La identificación de riesgos en un proyecto es completamente inútil si no se dan in-mediatamente los pasos necesarios para evitar el riesgo o para amortiguar su impacto. Elproceso de manejo de riesgos es sumamente importante y debe ser tratado con la mayorseriedad y profesionalismo. Una estrategia para administración de riesgos se muestra enla figura 1.13 y se explica en los párrafos subsecuentes.

Figura 1.13: Estrategia de gestión de riesgos

Es muy importante que el proyecto involucre representantes de cada uno de los rolesdel modelo de equipo. Cada rol estará en posición de identificar y entender diferentestipos de riesgo y de traerlos a la atención del resto del equipo.

Una vez logrado esto y que los riesgos se han puesto por escrito, se procede a anali-zarlos, a tratar de evaluar la posibilidad de que dichos riesgos se materialicen y, en casode que lo hagan, a evaluar el impacto que tendrían sobre el proyecto. Conociendo y enten-diendo las probabilidades e implicaciones, es posible entonces proceder a la elaboraciónde un plan para eliminar el riesgo, o bien, para reducir la probabilidad de que ocurra. Enlos casos en que la probabilidad de ocurrencia no puede ser eliminada, se debe diseñar unplan de contingencia adecuado.

El plan de atención a cada riesgo debe ser asignado a un propietario, que será lapersona responsable de darle seguimiento y facilitar la ejecución del plan. El paso finalen el proceso es la revisión o control de los riesgos en cartera, donde se determina si elriesgo ha sido eliminado, si la ejecución del plan de atención a ese riesgo en particularestá todavía en curso, o si no se puede eliminar, pero los planes de contingencia estánlistos. Dependiendo del resultado el riesgo se elimina o se mantiene en la lista.

El documento conteniendo la lista de riesgos vigentes debe ser revisado con la pe-riodicidad necesaria, misma que sólo puede ser estimada por los integrantes del equipo.Existirán períodos del proyecto en donde la revisión tenga que ser diaria, y periodos enlos que una revisión semanal sea suficiente.

Es altamente recomendable mantener el documento de evaluación de riesgos y los pla-nes relacionados en una escala manejable. Es decir, no se deben tener demasiados riesgos

Diseño y Arquitectura de Redes Telemáticas 24

Page 35: Diseño y Arquitectura de Redes Telemáticas

1.4. ANÁLISIS DE RIESGOS

siendo atacados al mismo tiempo. Nuevamente, esto depende del tamaño y complejidaddel proyecto.

Como regla general se debe procurar no manejar más de diez riesgos al mismo tiempo.

Una forma de superar esta limitante en proyectos grandes consiste en llevar un docu-mento de análisis de riesgo por rol del modelo de equipo, o por equipos de trabajo dentrodel proyecto. Sin embargo, es importante subrayar que deberá existir un documento prin-cipal que contenga la evaluación de riesgos globales del proyecto, el cual podrá conteneralgunos de los riesgos que están en documentos individuales, pero no todos ellos.

1.4.2. Caso de estudio: cuantificación del riesgo

El siguiente caso de estudio tiene por objeto mostrar cómo cuantificar el nivel deriesgo de un proyecto de redes. Se trata de un proyecto de integración de servicios entrelas tres ciudades más importantes de la República Mexicana3.

Cierta empresa con cobertura nacional cuenta con dos redes superpuestas: EnlacesFrame Relay en varios puntos de la República para transporte de datos, y enlaces privadosTDM para transporte de voz y datos.

La empresa desea migrar hacia una única red WAN multiservicios. En una primerafase, se diseña la red dorsal formada por un triángulo con puntos de presencia en México,Guadalajara y Monterrey (ver figura 1.14).

Figura 1.14: Red dorsal multiservicio entre las tres principales ciudades del país.

Una vez definido el diseño básico de la red y el plan de actividades, se llevó a cabo unarevisión detallada del proyecto tratando de identificar posibles riesgos y su impacto. En la

3Johansson, R.; Aplicación de metodologías de administración de proyectos para implantar un proyectode red; Tesina Ing. Telemática, ITAM, 2001.

Diseño y Arquitectura de Redes Telemáticas 25

Page 36: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

planeación de riesgos se deciden las tácticas de manejo que se utilizarán para disminuircada uno y posteriormente se evalúa el nuevo impacto que podrían tener, una vez aplicadasdichas tácticas.

El análisis de impacto y la planeación de riesgos se realizó en grupo y con ayuda deexpertos. Cada riesgo se evaluó según su probabilidad de ocurrencia y su impacto en elproyecto. Estos criterios fueron calificados de la siguiente manera:

Probabilidad de ocurrencia Impacto1 Muy poco probable (0-20 %) 1 Mínimo2 Poco probable (20-40 %) 2 Poco3 Puede ocurrir (40-60 %) 3 Moderado4 Probable (60-80 %) 4 Alto5 Muy probable (80-100 %) 5 Extremo

Los riesgos asociados al proyecto y su evaluación se presentan en la siguiente tabla.

Probabilidad/Descripción Impacto(A) ENTORNO DE NEGOCIO

A1 Fondos no asignados 1/5A2 Proyecto no ha sido justificado 2/5A3 Alta dirección no ha dado soporte 4/4

(B) ENTORNO DE PROYECTOB1 Objetivos no claros o no identificados 4/3B2 Alcances incompletos o no definidos 5/3B3 Estimados y costos no validados 4/3B4 Criterios de aceptación no claros 3/4B5 Mala comunicación 4/4B6 Pérdida de interés del patrocinador 2/4

(C) EL CLIENTEC1 No entiende un entorno de proyectos 2/3C2 Sin autoridad para tomar decisiones 3/1C3 Personal no participa en el proyecto 2/3C4 Insiste en utilizar equipo obsoleto de su propiedad 3/4C5 Tiempos largos de instalación en sitios remotos 3/4C6 No permite acceso a instalaciones 2/3C7 No tiene experiencia en proyectos similares 3/4C8 No está comprometido con el proyecto 1/2

(D) EL USUARIOD1 No involucrado en def. requerimientos 2/2D2 Demanda capacitación no factible 1/3D3 No está involucrado 1/3D4 No entiende el impacto 2/2D5 No tiene experiencia en proyectos similares 2/3

Diseño y Arquitectura de Redes Telemáticas 26

Page 37: Diseño y Arquitectura de Redes Telemáticas

1.4. ANÁLISIS DE RIESGOS

Probabilidad/Descripción ImpactoD6 No entiende un entorno de proyectos 2/3D7 No está comprometido con proy. 1/2

(E) LA SOLUCIÓN TÉCNICAE1 No ha sido realizada antes 2/3E2 Basado en métodos o herramientas no probadas 3/3E3 Se requiere de expertos para algunos equipos 2/4

(F) CALIDADF1 Req. calidad no bien documentados 1/2F2 Req. calidad no son entendidos 2/3F3 No se asegura la calidad del proyecto 2/2

(G) PROVEEDORES Y OTROS REC. HUMANOSG1 No hay equipos en mercado local 4/4G2 No hay proveedor de enlaces 1/4G3 Proveedor inestable económicamente o en situación desconocida 1/5G4 Tiempos de entrega muy prolongados 3/4G5 Falla de enlaces contratados 1/4G6 Falla de equipos entregados 1/5G7 Personal no tiene conocimientos req. 3/4G8 Personal especializado no disponible 2/4G9 Huelgas y paros laborales 1/3

(H) ADMINISTRACIÓN DE PROYECTOSH1 Administrador de proyectos con experiencia no ha sido asignado 3/4H2 Adm. proyectos no tiene experiencia en proyectos de esta magnitud 3/3H3 No se cuenta con una metodología formal de administración de proyectos 1/4

(I) FACTORES EXTERNOSI1 Actos del gobierno 1/1I2 Depreciación del tipo de cambio 2/3I3 Cambios en el Mercado 1/3I4 Legislaciones 1/3

Los riesgos se colocan en una matriz de impacto contra probabilidad:

ImpactoProbabilidad Mínimo Poco Moderado Alto Extremo

Muy probable B2Probable B1 B3 A3 B5 G1

B4 C4 C5 C7Puede ocurrir C2 E2 H2 G4 G7 H1C1 C3 C6 D5Poco probable D1 D4 F3 D6 E1 F2 I2 B6 E3 G8 A2

Muy poco D2 D3 G9probable I1 C8 D7 F1 I3 I4 G2 G5 H3 A1 G3 G6

Para cada riesgo, se propone un plan de manejo. El énfasis se concentra en aquellos

Diseño y Arquitectura de Redes Telemáticas 27

Page 38: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

riesgos colocados en el cuadrante superior derecho de la matriz anterior. Se tratará deeliminarlos o de llevarlos al cuadrante inferior izquierdo.

Los riesgos asociados al proyecto, su evaluación, el plan de manejo y su nueva eva-luación si se aplica el plan, se presentan en la siguiente tabla.

Prob/ NvaDescripción Impacto Plan Eval(A) ENTORNO DEL NEGOCIO

A1 Fondos no asignados 1/5 Asume riesgo 1/5A2 Proyecto no ha sido justifica-

do2/5 Identifica actores y justifica 1/5

A3 Alta dirección no ha dado so-porte

4/4 Ajusta alcances p/obtener soporte 2/4

(B) ENTORNO DE PROYECTOB1 Objetivos no claros o no iden-

tificados4/3 Clarifica con actores 2/2

B2 Alcances incompletos o nodefinidos

5/3 Completa y define 3/2

B3 Estimados y costos no valida-dos

4/3 Valida con los actores 2/2

B4 Criterios de aceptación noclaros

3/4 Explica criterios a los actores 1/2

B5 Mala comunicación 4/4 Establece y refuerza plan comunic. 2/2B6 Pérdida de interés del patroci-

nador2/4 Encuestas periódicas de satisfac-

ción2/3

(C) EL CLIENTEC1 No entiende un entorno de

proyectos2/3 Integra al cliente en el proyecto 1/2

C2 Sin autoridad para tomar de-cisiones

3/1 Asume riesgo 3/1

C3 Personal no participa en elproyecto

2/3 Asume riesgo 2/3

C4 Insiste en utilizar equipo ob-soleto de su propiedad

3/4 Clarifica requerimientos, motiva ycompromete para que acepte elcambio

2/4

C5 Tiempos largos de instalaciónen sitios remotos

3/4 Informar sobre la importancia derespetar calendario. Involucrar per-sonal del cliente con responsabili-dades

2/3

C6 No permite acceso a instala-ciones

2/3 Establece horarios de acceso y con-troles por si surgen problemas

1/3

C7 No tiene experiencia en pro-yectos similares

3/4 Involucra más al cliente 1/2

Diseño y Arquitectura de Redes Telemáticas 28

Page 39: Diseño y Arquitectura de Redes Telemáticas

1.4. ANÁLISIS DE RIESGOS

Prob/ NvaDescripción Impacto Plan EvalC8 No está comprometido con el

proyecto1/2 Asume riesgo 1/2

(D) EL USUARIOD1 No involucrado en def. de re-

querimientos2/2 Asume riesgo 2/2

D2 Demanda capacitación nofactible

1/3 Asume riesgo 1/3

D3 No está involucrado 1/3 Asume riesgo 1/3D4 No entiende el impacto 2/2 Asume riesgo 2/2D5 No tiene experiencia en pro-

yectos similares2/3 Involúcralo más en el proyecto 2/1

D6 No entiende un entorno deproyectos

2/3 Involúcralo más en el proyecto 1/2

D7 No está comprometido conproy.

1/2 Asume riesgo 1/2

(E) LA SOLUCIÓN TÉCNICAE1 No ha sido realizada antes 2/3 Encontrar expertos para las áreas

relevantes2/1

E2 Basado en métodos o herra-mientas no probadas

3/3 Encontrar expertos para las áreasrelevantes

3/1

E3 Se requiere de expertos paraalgunos equipos

2/4 Encontrar expertos para las áreasrelevantes

2/2

(F) CALIDADF1 Req. de calidad no bien docu-

mentados1/2 Asume riesgo 1/2

F2 Req. de calidad no son enten-didos

2/3 Aclara requerimientos a los actores 1/3

F3 No se asegura la calidad delproyecto

2/2 Asume riesgo 2/2

(G) PROVEEDORES Y OTROS REC. HUMANOSG1 No hay equipos en mercado

local4/4 Busca en otro mercado e importa 4/2

G2 No hay proveedor de enlaces 1/4 Busca otras soluciones: más enlacesde menor capacidad; otra tecnolo-gía; etcétera.

1/2

G3 Proveedor inestable económi-camente o en situación desco-nocida

1/5 Busca proveedores secundarios,apalanca vía fianzas y seguros

1/3

G4 Tiempos de entrega muy pro-longados

3/4 Estima tiempos en exceso 3/2

Diseño y Arquitectura de Redes Telemáticas 29

Page 40: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

Prob/ NvaDescripción Impacto Plan EvalG5 Falla de enlaces contratados 1/4 Resuelve problema con proveedor;

busca enlaces alternos1/2

G6 Falla de equipos entregados 1/5 Resuelve problema o busca provee-dor alterno con entregas rápidas

1/1

G7 Personal no tiene conoci-mientos requeridos

3/4 Capacita al personal 2/4

G8 Personal especializado nodisponible

2/4 Contrata consultor experto; capaci-ta

2/2

G9 Huelgas y paros laborales 1/3 Asume riesgo 1/3(H) ADMINISTRACIÓN DE PROYECTOS

H1 Administrador de proyectoscon experiencia no ha sidoasignado

3/4 Busca administrador con más expe-riencia

2/3

H2 Adm. proyectos no tiene ex-periencia en proyectos de estamagnitud

3/3 Busca administrador con más expe-riencia

1/3

H3 No se cuenta con una meto-dología formal de administra-ción de proyectos

1/4 Implanta administrador y metodo-logía

1/2

(I) FACTORES EXTERNOSI1 Actos del gobierno 1/1 Asume riesgo 1/1I2 Depreciación del tipo de cam-

bio2/3 Asume riesgo 2/3

I3 Cambios en el Mercado 1/3 Asume riesgo 1/3I4 Legislaciones 1/3 Asume riesgo 1/3

Con las re-evaluaciones se colocan nuevamente en la matriz de impacto contra proba-bilidad.

ImpactoProbabilidad Mínimo Poco Moderado Alto Extremo

Muy probableProbable G1

Puede ocurrir E2 B2 C2 G4B1 B3 B5 D1 B6 C3 C5Poco probable D5 E1 D4 E3 F3 G8 H1 I2 A3 C4 G7

B4 C1 C7 C8 C6 D2 D3 F2Muy poco G6 I1 D6 D7 F1 G2 G3 G9 H2 I3 A1 A2probableG5 H3 I4

Cada celda en la matriz recibe una ponderación reflejando el peso relativo de un im-pacto en esa celda.

Diseño y Arquitectura de Redes Telemáticas 30

Page 41: Diseño y Arquitectura de Redes Telemáticas

1.5. PROBLEMAS

ImpactoProbabilidad Mínimo Poco Moderado Alto Extremo

Muy probable 2.0 3.5 7.0 8.0 9.0Probable 1.5 2.0 5.0 7.0 8.0

Puede ocurrir 1.2 1.8 4.0 5.0 7.0Poco probable 1.0 1.5 3.0 4.0

Muy poco probable 0.5 1.0 1.5 3.0 4.0

El factor de riesgo del proyecto, se deriva del promedio ponderado de los riesgosidentificados.

Promedio ponderado =

5∑i=1

5∑j=1

ni,j · pi,j

N= 1.7,

donde N es el número de riesgos considerados y ni,j los riesgos en la celda {i, j} la cualtiene un peso pi,j .

El nivel de riesgo se asocia tomando como referencia una tabla como la siguiente:

Riesgo del proyecto RangoMuy bajo 0 a 0.49

Bajo 0.5 a 1.49Medio bajo 1.5 a 3.99

Medio 4.0 a 5.99Medio alto 6.0 a 7.49

Alto 7.5 a 8.49Muy alto 8.5 a 9.0

1.5. Problemas

1.1. Describa brevemente en qué consiste el método descendente de diseño de redesvisto en clase.

1.2. Mencione tres de las principales razones por las que un proyecto de tecnologíade información puede fallar.

1.3. De acuerdo a los reportes CHAOS de The Standish Group las principales cau-sas de fracaso en los proyectos de TI no tienen que ver con aspectos técnicos o deingeniería. Explique brevemente esta afirmación.

1.4. ¿Por qué es mejor realizar un proceso de diseño descendente y cuál es la con-dición esencial para iniciar el proceso?

Diseño y Arquitectura de Redes Telemáticas 31

Page 42: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

1.5. El modelo de proceso de MSF cuenta típicamente con cinco etapas: Visión,Planeación, Desarrollo, Estabilización y Despliegue ejecutadas en ese orden. Sinembargo, en la metodología presentada se siguieron únicamente cuatro de ellas.¿Está usted de acuerdo con ello? ¿Por qué?

1.6. ¿En qué consisten las fases del modelo de proceso propuesto por MSF? ¿Cuálesson los entregables en cada una de ellas?

1.7. ¿Por qué es importante tener una visión clara y compartida, así como objetivosSMART en un proyecto MSF?

1.8.

(a) Nombre las etapas faltantes en el diagrama de ciclo de vida de un proyectode red.

=⇒ =⇒

⇐= ⇐=

⇑ ⇓

Gestión Desarrollo

Análisis

(b) Mencione dónde entra cada una de estas etapas en el modelo de procesode MSF.

1.9. De acuerdo al modelo de proceso de MSF, ¿Cuándo y dónde se determina el“qué, cómo y cuándo” de un proyecto de tecnología?

1.10. Si varios requerimientos de diseño entraran en conflicto, ¿cómo se puede ob-tener una guía para definir el diseño de red más apropiado?

1.11. Al proponer su modelo de proceso, Microsoft pretende integrar las mejoresideas de las populares metodologías “de cascada” y “espiral” de desarrollo de soft-ware. Explique brevemente en qué consiste esta afirmación.

1.12. Se le contrata en una cadena de tiendas departamentales para desarrollar unproyecto cuyo objetivo es “reducir los tiempos de respuesta del sistema en cajaspara reducir el tiempo que deben esperar los clientes al pagar”. De acuerdo a loslineamientos del modelo de proceso de MSF, ¿el planteamiento del objetivo es co-rrecto? ¿Por qué?

1.13. De acuerdo a la fase de desarrollo en el modelo de proceso de MSF,

(a) ¿Qué es la prueba de concepto?

(b) ¿Qué es el piloto?

(c) ¿Qué consideraciones se deben tener en cuenta para pasar de la prueba deconcepto al piloto?

Diseño y Arquitectura de Redes Telemáticas 32

Page 43: Diseño y Arquitectura de Redes Telemáticas

1.5. PROBLEMAS

1.14. En las primeras etapas del modelo de proceso, se generan los borradores delplan maestro, del calendario maestro y de la especificación funcional. (a) ¿Por quéson borradores? (b) ¿En cuáles se definen los objetivos SMART? (c) ¿Quién losrealiza y quién los autoriza?

1.15. Investigue cuáles son los integrantes del modelo de equipo propuesto por MSFy mencione brevemente la función de cada uno de ellos.

1.16. Para los proyectos pushed by technology (PT) y pulled by demand (PD), tam-bien llamados market pulled,

(a) Describa muy brevemente en qué consisten y roporcione un ejemplo decada uno.

(b) ¿Considera que debería modificarse de alguna manera la metodología vistaen clase en función del tipo de proyecto (PT, PD)?

(c) ¿Qué factores considera críticos para un análisis de retorno en función deltipo de proyecto?

1.17. Suponga que la Comisión Federal de Comunicaciones (FCC) de los EstadosUnidos decide reasignar las bandas de espectro para televisión UHF para accesoa internet con radios cognitivos, en el año X. Suponga una iniciativa similar enMéxico para el año X+2. ¿Esta iniciativa sería pushed by technology, by demand, osimplemente una moda?

1.18. Del documento NETWORK PLANNING AND DESIGN de R. Van Slyke4,lea las primeras dos secciones y el caso de estudio del anexo B, y responda lassiguientes preguntas:

(a) Suponiendo que en su empresa se va a desarrollar un gran proyecto dedesarrollo de redes a lo largo del año, identifique 10 riesgos técnicos y 10de factores externos que podrían presentarse. Posiciónelos en una matriz deprobabilidad/impacto. Justifique su respuesta.

(b) ¿Cuál es la estrategia organizacional para TI en su empresa? ¿Están cla-ramente identificadas las políticas para desarrollo y actualización de tecnolo-gías? Explique brevemente.

(c) Suponga que, similar a las tarjetas IAVE, la SCT desarrolla un sistema parapagar las casetas de cobro a través del teléfono celular. ¿Esta aplicación seríapush-driven o pull-driven?

(d) ¿La tecnología SMS exhibe un comportamiento de economía de escalao de economía de red? Explique brevemente. En este contexto, una empresaencuestadora orientada al segmento de jóvenes que utiliza SMS para sus eva-luaciones, ¿sería push-driven o pull-driven?

4cis.poly.edu/rvslyke/ndr1.pdf

Diseño y Arquitectura de Redes Telemáticas 33

Page 44: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 1. METODOLOGÍA DE DISEÑO DE REDES

(e) En la medida de lo posible, relacione los 12 puntos de la metodologíapropuesta en el documento con las cuatro fases del modelo de proceso MSF.¿Cuáles son las principales diferencias entre ambos?

(f) Revise los portales de Amazon y Barnes and Noble y comente brevementesobre la forma en que cada uno ha diversificado su oferta de productos desdela fecha en que fue escrito el documento.

(g) Responda las cuatro primeras preguntas el cuestionario del anexo B.

1.19. Para el análisis de riesgos de un proyecto, se ha propuesto que los riesgosidentificados se coloquen en una matriz.

(a) ¿Qué contienen los renglones y columnas de esta matriz?

(b) ¿Para qué se asigna una ponderación a cada celda en la matriz?

1.20. ¿Qué diferencia hay entre mitigar un riesgo y hacer un plan de contingencia?

1.21. Para cierto proyecto, se han identificado los riesgos que aparecen en la tablasiguiente. Suponiendo que tanto la probabilidad (Pr) de ocurrencia como su impacto(Im) pueden tomar valores de 1 a 3, complete la tabla y otorgue una calificaciónfinal al proyecto. Dada la vaguedad de la pregunta, debe justificar sólidamente losvalores que asigne.

Riesgo Pr Im JustificaciónFalta soporte Alta DirecciónCriterios de aceptación no clarosTiempos largos de instalación ensitioCliente inmediato no tiene autori-dad para tomar decisionesUsuario no está involucradoSolución con base en tecnologíasno probadas, no conocidasNo se tienen estrategias de controlde calidadEl proveedor de servicios (ca-rrier) falla, quiebraHay una devaluación de la mone-daNo hay líder de proyectos o notiene experiencia

Diseño y Arquitectura de Redes Telemáticas 34

Page 45: Diseño y Arquitectura de Redes Telemáticas

Capítulo 2

Requerimientos técnicos. Compromisosy restricciones

Durante la fase de visión y alcance se identificaron las necesidades de negocio, elentorno de trabajo y se empezó a reconocer el tipo de aplicaciones que soportarán losobjetivos del proyecto. Para el diseño de la red, los requerimientos de negocio se traducenen requerimientos técnicos.

Como se mencionó en el capítulo anterior, los objetivos del proyecto deben ser SMART,por lo que los requerimientos técnicos deben ser cuantificables y especificarse en térmi-nos concretos. En este capítulo se introducirán brevemente algunos de los requerimientostécnicos encontrados más frecuentemente en redes de comunicaciones. Específicamente,se presentan los requerimientos de:

Escalabilidad

Desempeño

Administración

Adaptabilidad

Disponibilidad

Seguridad

Facilidad de uso

Costo-beneficioAlgunos de estos requerimientos son mutuamente exclusivos, por lo que se requiere

de compromisos entre ellos. Estos compromisos deben estar claramente alineados con losobjetivos del proyecto.

2.1. Escalabilidad

El requerimiento de escalabilidad (scalability) se refiere básicamente a la capacidadde crecimiento de la red y puede llegar a ser uno de los objetivos centrales para medianasy grandes empresas inmersas en una estrategia de adquisiciones, fusiones, y/o crecimientoacelerado.

En este contexto, “crecimiento” abarca varias dimensiones. Se debe discutir clara-mente con el cliente cuáles son sus planes a corto (un año), mediano (dos años) y largo

Page 46: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

plazo (cinco años) para agregar nuevos usuarios, equipos y aplicaciones de negocio. Tam-bién deberá discutirse si se tienen planeados cambios en las políticas de operación (porejemplo, comercio electrónico) y/o en las principales líneas de negocio.

Esto es muy importante pues escalar una red puede llegar a ser sumamente difícilsi no se planea desde el principio. Por ejemplo, algunas tecnologías son inherentementeno escalables, como ocurre con redes planas basadas en equipos de conmutación y queutilizan protocolos que generan muchas tramas de difusión.

La escalabilidad será confrontada con el tiempo de vida promedio de las tecnologíasen que se basa el diseño propuesto. Es común considerar que la infraestructura de base(cableado, enlaces) tiene un tiempo de vida útil de 10 a 15 años. Sin embargo, en los últi-mos años se ha observado un cambio dramático en la tasa de rotación de infraestructura.

A partir de finales del siglo XX se observó un tiempo de obsolescencia de la infra-estructura de cableado de únicamente seis años, sobre todo en el núcleo de la red,debido a las continuas mejoras tecnológicas y a la reducción de costos en este rubro(en particular, en fibra óptica). Este tiempo de obsolescencia sigue siendo vigente enredes que no han desplegado fibra óptica monomodal.Para los equipos de conmutación (enrutadores, conmutadores, concentradores), eltiempo de vida actual oscila entre los tres y los cinco años.

Otro aspecto que debe tomarse en consideración al evaluar la escalabilidad necesariaen la red, es que los paradigmas clásicos de dimensionamiento de redes están perdiendofuerza. Tradicionalmente, la planeación de capacidad para redes empresariales se hacíabasándose en una distribución Pareto: 80 % del tráfico queda en la red local departamentaly 20 % va a otros lados. Este paradigma ha sido cada vez más cuestionado en la actualidad.De hecho, se observa que la relación se está invirtiendo debido, entre otros factores, a:

el uso creciente de granjas de servidores (clusters, blade servers) y de servidores deaplicaciones;

el modelo de hospedaje externo de servidores (hosting);

la concentración de información en infraestructura especializada (SANs, NAS);

la difusión de información corporativa en intranets;

el creciente modelo de comunicaciones inter-empresas (extranets).

2.2. Disponibilidad

La disponibilidad (availability) indica cuánto tiempo la red está en operación en undeterminado intervalo de tiempo (año, mes, día, hora, . . . ). Generalmente se representacomo un porcentaje del período evaluado.

Disponibilidad =Tiempo en operación

Período evaluado

Diseño y Arquitectura de Redes Telemáticas 36

Page 47: Diseño y Arquitectura de Redes Telemáticas

2.2. DISPONIBILIDAD

De acuerdo a su disponibilidad, los sistemas pueden clasificarse de la siguiente mane-ra:

No administrado 90 %Administrado 99 %Bien administrado 99.9 %Tolerante a fallos 99.99 %Alta disponibilidad 99.999 %Muy alta disponibilidad 99.9999 %Ultra alta disponibilidad 99.99999 %

La disponibilidad necesaria debe definirse con precisión, pues cada “9” adicional, sibien aumenta en un orden de magnitud la fiabilidad del sistema, puede resultar sumamentecostoso. Para saber cuánto invertir en este requerimiento, debe partirse por evaluar el costopara la empresa de que una aplicación de misión crítica deje de operar.

Las aplicaciones de misión crítica son todos aquellos procesos en los que se basa elnúcleo de negocio de la empresa. Un fallo en una aplicación crítica deja a la empre-sa sin poder operar. Un requerimiento de disponibilidad típico para aplicaciones demisión crítica es de 99.98 %.

La disponibilidad se puede determinar más fácilmente a partir de los valores de tiempomedio entre fallos (mean time between failures, MTBF) y tiempo medio de reparación(mean time to repair, MTTR).

Disponibilidad = A =MTBF

MTBF + MTTR

Se prefiere esta métrica pues puede ocurrir que muchas fallas de muy corta duraciónden un valor de disponibilidad adecuado aunque en la práctica no se pueda trabajar con elsistema.

MTBF y MTTR son cifras para componentes y equipos. Como la red da un servicio,algunos autores prefieren los términos MTBSO (Mean time between service outages) yMTTSR (Mean time to service repair).

Es muy importante considerar que los valores de MTBF y MTTR son valores prome-dio en los que puede haber una gran variabilidad. Esto es particularmente cierto para elMTTR, en el cual se engloban muchos factores muy variados como el tiempo en que sedetecta la falla, el necesario para aislar el equipo, para repararlo, y el tiempo necesariopara restablecer el equipo e integrarlo a la infraestructura de producción.

Para un equipo de red, un MTBF deseable es del orden de decenas de miles de horas.Para un sistema completo, es de miles de horas, pues la disponibilidad de un sistemadepende de la manera en la que sus componentes están interconectados:

Dado que 0 ≤ Ai ≤ 1, de la figura 2.1 se confirma que con un mayor número dedispositivos o sub-sistemas en serie, la disponibilidad disminuye (es decir, aumenta laprobabilidad de fallos en el sistema). A mayor número de dispositivos –con la misma

Diseño y Arquitectura de Redes Telemáticas 37

Page 48: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

As = A1 × A2

Ap = A1 + A2 − A1 × A2

Figura 2.1: Disponibilidad de sistemas con componentes en serie y en paralelo

funcionalidad– en paralelo, la disponibilidad aumenta. Es evidente que el uso de equiposredundantes aumenta la disponibilidad del sistema.

Para sistemas similares que no están directamente relacionados entre sí, los MTBF (yen cierta medida, la disponibilidad) de cada uno suelen considerarse como variables alea-torias independientes idénticamente distribuidas.

EJEMPLO 2.1. Considere una empresa que tiene N = 500 computadoraspersonales con un MTBF de 10, 000 hr. El número de incidentes por fallosesperado por día es de:

X = N× t

MTBF + MTTR≈ N× t

MTBF= 500× 8760

365× 10000= 1.2 fallos/dia

Tal vez se justifique una persona dedicada a dar mantenimiento a las compu-tadoras. Si se adquirieran equipos con un MTBF de 40, 000 hr, entonces setendrían 9 fallos por mes.

2.3. Confiabilidad

La confiabilidad (reliability) se refiere a las características aleatorias de los fallos. Sedefine como la probabilidad de que el sistema no falle antes de t horas de operación y seespecifica en términos del MTBF de los componentes.

Frecuentemente se considera que las fallas obedecen a un proceso de Poisson, por loque el intervalo entre fallos tiene una distribución exponencial. Por lo tanto,

R = e−t

MTBF

Diseño y Arquitectura de Redes Telemáticas 38

Page 49: Diseño y Arquitectura de Redes Telemáticas

2.4. DESEMPEÑO

EJEMPLO 2.2. Considere un equipo con un MTBF = 10, 000 horas. Su con-fiabilidad para un año será deR = 41.64 %. Si el MTBF aumenta a 20, 000 horas,la confiabilidad únicamente crece a R = 64.53 %.

Como fue el caso para el requerimiento de disponibilidad, la confiabilidad de un sis-tema depende de la interconexión entre sus componentes. Para una topología en serie, laconfiabilidad se calcula así:

Rs = e−t(

1MTBF1

+ 1MTBF2

+···+ 1MTBFn

),

mientras que para un sistema con componentes similares en paralelo, la confiabilidad sedetermina por:

Rp = 1− (1−R1)× (1−R2)× · · · × (1−Rn).

EJEMPLO 2.3. Considere un sistema con tres componentes en serie cuyosMTBF son respectivamente de 20 k, 25 k y 30 k horas. Para un año, la confia-bilidad del sistema es: R = 34 %.

2.4. Desempeño

Los requerimientos de desempeño de la red (network performance) también llamados“prestaciones de la red”, se definen con base en un conjunto de métricas cuantitativassobre el comportamiento de la red, como el ancho de banda, la utilización, el rendimiento,la carga ofrecida, la tasa de error, la eficiencia, el retardo y su variabilidad (jitter).

Es importante identificar las expectativas que el usuario tiene sobre el desempeño dela red. Estas expectativas están fuertemente ligadas a las características de la red existentey a los planes de crecimiento de la misma.

2.4.1. Ancho de banda

Técnicamente, el ancho de banda es una medida del rango de frecuencias que confor-man una señal analógica (o la mayor parte de su potencia) y está medida en Hertz. En lossistemas digitales, representa el número de símbolos por segundo o baudios que puedenser transmitidos por un sistema de comunicaciones.

Dependiendo de la técnica de codificación, cada baudio puede representar uno o másbits, por lo que el ancho de banda también se emplea informalmente como una medidade la capacidad del canal de comunicación. Esa es la definición que se seguirá en estedocumento: Es la cantidad nominal (o teórica) de información que puede ser transportadapor unidad de tiempo. Generalmente se expresa en bits/s.

Diseño y Arquitectura de Redes Telemáticas 39

Page 50: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

2.4.2. Utilización

Es una medida de la cantidad de tráfico transportada en relación con la capacidad total.En primera instancia se podría pensar que el objetivo de utilización debería ser cercano al100 % pero en realidad esto no es así:

En las redes informáticas los paquetes suelen llegar en ráfagas y se debe dejar unmargen para poder absorber esas ráfagas sin que haya pérdidas.

En redes que tienen un control de acceso por contención (por ejemplo, ethernet), laeficiencia (ver más adelante) disminuye rápidamente conforme aumenta la utiliza-ción.

Los procesos de llegada y de salida de paquetes son procesos aleatorios. En la ma-yoría de los casos, la dinámica de estos procesos requiere que, para una tasa depérdida determinada, el tamaño de los buffers (y por consiguiente, el tiempo deespera) aumente exponencialmente conforme la utilización se acerca al 100 %.

EJEMPLO 2.4. Un modelo de la teoría de colas muy común para evaluarmétricas de desempeño en redes de conmutación de paquetes, es la colaM/M/11. La cola M/M/1 supone que la llegada de los paquetes es un pro-ceso de Poisson (el intervalo entre paquetes tiene una distribución aleatoriaexponencial) y que la tasa de servicio (la longitud del paquete) también esexponencial.

En este modelo, la utilización es el cociente entre la tasa de llegadas y la tasade servicio y se representa por ρ. El valor esperado para el tamaño de la colase calcula como:

E[N ] =ρ

1− ρ

Suponga que cinco usuarios generan tráfico con una tasa media de 10 paque-tes por segundo cada uno y que el tamaño medio de paquete es de 1,024 bits.Los cinco usuarios comparten un enlace E02. Modelando este escenario comouna cola M/M/1:

ρ =5× 10× 1, 024

64, 000= 0.8

E[N ] =0.8

0.2= 4

El número medio de paquetes encolados es de cuatro. Sin embargo, si se a-grega solamente un usuario más al sistema, entonces ρ = 0.96 y E[N ] = 24.

1Este no es un buen modelo para representar tráfico de datos, pero sigue siendo popular dada su sencillez.2E0=64,000 bits/s

Diseño y Arquitectura de Redes Telemáticas 40

Page 51: Diseño y Arquitectura de Redes Telemáticas

2.4. DESEMPEÑO

Los parámetros típicos para dimensionar una red informática son los siguientes:

Enlaces punto a punto y redes con control de acceso arbitrado: U ≈ 70 %

Redes ethernet: U ≈ 37 %

Los mecanismos de contención utilizados en ethernet, y derivados de la red Aloha,hacen que cuando la red empieza a rebasar este valor, el número de colisiones para acce-der al medio crezca demasiado. Sin embargo, se debe tener presente que esto no aplica aethernet conmutado, la tecnología dominante en la actualidad. Si en el puerto de un con-mutador ethernet se tiene conectado un solo equipo, se trata de un enlace punto a punto yla utilización puede crecer hasta el 70 %.

2.4.3. Rendimiento

En este trabajo, rendimiento (throughput) se define como la cantidad de informacióntransmitida sin error por unidad de tiempo. Idealmente, el rendimiento aumenta lineal-mente con la carga ofrecida a la red. Esto se cumple sólo hasta un cierto punto tras elcual se degrada debido a factores como la tasa de errores, la dinámica de protocolos, eldesempeño de los equipos intermedios y el modo de acceso.

El rendimiento puede ser calculado para toda la red, para una trayectoria, para unenlace o para un dispositivo de conmutación. En este último caso, el rendimiento se definecomo la tasa a la que el dispositivo puede conmutar paquetes, y puede variar de acuerdo altamaño medio del paquete. La tasa máxima de conmutación se conoce como wire speedy es igual a:

Wire speed =Ancho de banda

Tamaño de paquete

EJEMPLO 2.5. Para una red 10baseT, considerando tramas de tamaño míni-mo, la tasa máxima de conmutación de paquetes es:

10× 106

(64 + 20)× 8= 14, 480 p/s,

donde los 20 octetos en el denominador corresponden a 8 de preámbulo y 12del intervalo entre tramas.

Si se hace el mismo cálculo para un tamaño de trama de 1,500 bytes, entoncesel rendimiento sería de 822 p/s.

Desde el punto de vista del usuario, la métrica de rendimiento de interés es la tasade información percibida en la capa de aplicación del modelo de referencia para la in-terconexión de sistemas abiertos (OSI, Open Systems Interconnection). Esta métrica esinformalmente conocida como goodput.

Diseño y Arquitectura de Redes Telemáticas 41

Page 52: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

Por ejemplo, en una red de baja velocidad se podría eliminar cualquier mecanismo decompresión. En ese caso, tal vez el rendimiento a nivel enlace aumente pero ciertamenteel goodput se vería penalizado. Un caso similar ocurriría si la mayoría de los paquetes quecirculan por la red fueran retransmisiones debidas a algún equipo que no esté trabajandocorrectamente.

También conviene recordar que no todas las aplicaciones necesitan –o pueden generar–un goodput elevado. Considere, por ejemplo, una sesión interactiva de terminal virtual,sobre todo, con una interfaz de texto.

2.4.4. Tasa de error

Evidentemente, los datos recibidos deben ser iguales a los transmitidos. De no ser así,la trama debe ser emitida nuevamente, disminuyendo el rendimiento de la red. La tasa deerror es una medida del número de errores detectados. En medios físicos y redes WANgeneralmente se expresa en bits afectados (bit error rate) mientras que en redes LAN sehabla de tasa de tramas afectadas (frame error rate).

Antiguamente la tasa de error en los medios físicos era relativamente elevada. Estoha cambiado radicalmente en la actualidad, sobre todo con la aparición de la fibra óptica,aunque también ha habido mejoras en las demás tecnologías. Algunas fuentes típicas deerror son la siguientes:

Interferencia electromagnética (cable no blindado);

picos de corriente (medios cableados);

factores ambientales (microondas y satélites);

impedancias no acopladas (redes locales);

fallas de equipo (todos los casos).

Dada la penetración de los sistemas digitales en la actualidad, llama la atención queen la lista anterior no se consideren errores de software en los equipos terminales y dis-positivos de red. En realidad, este tipo de error suele detectarse rápidamente en las etapasde validación del equipo; es relativamente poco frecuente que un equipo en producciónpresente fallas de programación.

Algunas cifras típicas de tasa de error son las siguientes:

Alambre de cobre: BER ≈ 10−6

Fibra óptica: BER ≈ 10−12

Enlaces satelitales: BER ≈ 10−5. La tasa de error de los enlaces satelitales de-pende en gran medida de la banda (frecuencia) que se utilice y de las condicionesatmosféricas. La cifra anterior no considera la corrección automática de errores por

Diseño y Arquitectura de Redes Telemáticas 42

Page 53: Diseño y Arquitectura de Redes Telemáticas

2.4. DESEMPEÑO

el receptor (forward error correction, FEC), una técnica muy popular basada entransmisión de información redundante, lo cual permite reducir sustancialmente latasa efectiva de error.

Para redes LAN, una tasa de error considerada aceptable es detectar, en promedio,una trama errónea por cada 106 bytes transmitidos. Aunque se habla de tramaserróneas, la cifra se expresa en función del número de octetos para evitar el tenerque tomar en cuenta el tamaño de las tramas.

En redes tipo ethernet, se deben detectar menos de 0.1 % de tramas en colisión. Enprimera instancia, esta cifra puede parecer demasiado baja pues las colisiones sonun fenómeno “natural” de competencia en este tipo de redes. Sin embargo, se deberecordar que la mayoría de las colisiones se presentan durante la transmisión delpreámbulo, antes de iniciar propiamente la transmisión de una trama y por lo tanto,no son tomadas en cuenta.

2.4.5. Eficiencia

La eficiencia es una medida de la sobrecarga o trabajo extra necesario para la trans-misión de información en relación con la capacidad total del medio. También puede re-presentar la cantidad útil de información en relación con la cantidad transmitida. Se veafectada directamente por las características de los protocolos utilizados: tamaño de losencabezados, acuses de recibo, paso de estafetas (token); etc.

EJEMPLO 2.6. Del ejemplo 2.5 se obtuvo que en ethernet a 10Mb/s se pue-den enviar 14, 480 tramas de 64 bytes. Considerando únicamente la sobrecar-ga del encabezado MAC, en la trama sólo hay 64 − 18 = 46 bytes de cargaútil, por lo que la eficiencia es:

E =46× 14, 480× 8

10× 106× 100 % = 53.20 %.

Si el tamaño de las tramas cambia a 1,500 bytes, la eficiencia aumenta a:

E =1, 482× 812× 8

10× 106× 100 % = 96.20 %.

EJEMPLO 2.7. En transmisiones de voz sobre IP, cada paquete transporta uncierto intervalo de muestras (típicamente, 10, 20 o 40ms) cuyo tamaño de-pende del tipo de códec utilizado. Los paquetes suelen contener encabezadosde tres protocolos que contribuyen en 40 bytes al tamaño final del paquete:RTP (12 bytes), UDP (8 bytes) e IP (Ver. 4 sin opciones: 20 bytes). Igno-rando por ahora el encabezado MAC y suponiendo un códec PCM a 64 kb/s

Diseño y Arquitectura de Redes Telemáticas 43

Page 54: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

(G.711), si el paquete transporta 20ms de información, su eficiencia es lasiguiente:

Se generan 1/20ms = 50 p/s. Cada paquete tiene su propio encabezado porlo que se genera una sobrecarga de 50×40×8 = 16 kb/s. El ancho de bandanecesario para transportar la información es entonces de 16 kb/s+64 kb/s =80 kb/s y la eficiencia es:

E =64, 000

80, 000× 100 % = 80 %.

Es claro que una manera de aumentar la eficiencia es aumentando la carga útil (pay-load) por paquete para “prorratear” mejor el costo de los encabezados. Sin embargo,paquetes de mayor tamaño tienen una mayor probabilidad de error y –sobre todo en redesde baja velocidad– pueden introducir retardo y jitter en flujos concurrentes.

2.4.6. Retardo y variabilidad

Retardo (latencia) es el tiempo transcurrido entre la emisión de un paquete y su llegadaal extremo opuesto (retardo en una dirección), o bien, el arribo de su respuesta (retardode ida y vuelta, RTT). Afecta a las aplicaciones interactivas: Estudios recientes indicanque la mayoría de los usuarios esperan que algo ocurra en la pantalla tras una décima desegundo. La variabilidad en el retardo, el jitter, es un fenómeno que afecta principalmentea las aplicaciones multimedia.

Tanto el retardo como el jitter dependen de factores como el nivel de congestión, latípica emisión en ráfagas de las aplicaciones tradicionales y el desempeño de los enruta-dores (por ejemplo, durante la actualización de tablas de ruteo; tiempo de convergenciatras una falla; etc.).

Jitter

Se genera principalmente debido al tiempo de espera en las colas de los dispositi-vos de red. Como se ha señalado, el tiempo de espera aumenta exponencialmente con lautilización (en una disciplina de servicio FIFO).

Afecta a las aplicaciones multimedia pues las muestras transportadas por la red debenser “liberadas” exactamente con las mismas características temporales (cadencia e inter-valo entre muestras) con las que fueron tomadas. Una práctica común para compensar lasvariaciones sufridas en la red, es agregar un sello de tiempo a las muestras y utilizar unbuffer de reproducción en el receptor en el que se almacenan (y retrasan) temporalmentelos paquetes recibidos.

En principio, este buffer debe poder almacenar tantas muestras como para absorber lavariabilidad más grande esperada, pero en aplicaciones interactivas no puede ser dema-siado grande pues se pierde la sensación de continuidad necesaria en estos casos.

Diseño y Arquitectura de Redes Telemáticas 44

Page 55: Diseño y Arquitectura de Redes Telemáticas

2.4. DESEMPEÑO

Cuando se desconocen los requerimientos reales de jitter, una práctica común es re-comendar que éste no exceda el 2 % del valor de latencia especificado.

Elementos de retardo

Los principales elementos de retardo en una red se muestran en la figura 2.2:

Figura 2.2: Principales elementos de retardo en una red

Tiempo de procesamiento: tpr. En los equipos terminales, está relacionado con el tra-tamiento del paquete en la pila de protocolos y en el mecanismo de manejo deinterrupciones. Para sistemas de muy alto desempeño, se deben buscar implemen-taciones que minimicen el número de transferencias a memoria durante el procesa-miento del paquete por los distintos procesos que intervienen en su manejo (zerocopy stacks).

En los nodos de conmutación está relacionado con la arquitectura interna del dispo-sitivo para seleccionar la interfaz de salida y llevar el paquete hacia ella. Un valortípico para equipos de no muy alto desempeño es de entre 10 y 50µs. Para algu-nas arquitecturas, este valor está en función del tamaño del paquete. El tpr tambiénpuede incluir el tiempo medio de espera en los buffers del dispositivo.

Tiempo de acceso al medio: ta. Es el intervalo de espera para poder iniciar la transmi-sión y depende del protocolo de acceso al medio particular (contención, espera deautorización, de la ranura de tiempo, etc.).

Tiempo de transmisión: tt. También llamado de serialización, indica el tiempo requeri-do para “colocar” el paquete en el medio y es igual a la longitud del paquete divididaentre la velocidad de transmisión.

Tiempo de propagación: tp. Es el tiempo que se requiere para propagar la energía (encualquier formato) de un punto a otro. Se calcula como la distancia del medio divi-dida entre la velocidad de propagación. La velocidad de propagación de las ondaselectromagnéticas es la velocidad de la luz: c ≈ 3× 108m/s3. La velocidad de pro-pagación tanto en cobre como en fibra óptica suele ser tomada como 2

3c, aunque los

valores más exactos que se tienen hasta el año de 2002 son de 224, 844 km/s en unalambre de cobre y de 194, 865 km/s en una fibra óptica multimodal.

3Más precisamente, 299, 792, 458 km/s.

Diseño y Arquitectura de Redes Telemáticas 45

Page 56: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

EJEMPLO 2.8. Considere la red de la figura 2.2 con las siguientes caracte-rísticas:

La red LAN en el origen es 10BaseT;

la red LAN en el destino es 100BaseT;

las entidades se encuentran a 900 km de distancia y están interconecta-das con un enlace E0;

el origen envía una trama de 1 kB y espera el acuse de recibo de 64bytes.

Para calcular el RTT, se tomarán en cuenta las siguientes consideraciones:

El tiempo de procesamiento en el origen y el destino se ignora;

el retardo de propagación en las redes locales se ignora;

el tiempo de procesamiento en los enrutadores es de 10µs;

tto, ttd y ttw son los tiempos de serialización de las dos tramas en elorigen, en el destino y en el enlace WAN, respectivamente.

tto =(1, 024 + 64)× 8

106= 0.87ms

ttd =(1, 024 + 64)× 8

107= 0.087ms

ttw =(1, 024 + 64)× 8

64, 000= 136ms

tpr = 0.04ms

tp = 2× 900

240, 000= 7.5ms

RTT = tto + ttd + ttw + tpr + tp = 144.49ms

El principal elemento de retardo es el tiempo de serialización en el enlaceWAN. Este es el cuello de botella. Se dice que esta red está limitada enancho de banda.

EJEMPLO 2.9. Se retoman las condiciones del ejemplo anterior, pero el en-lace de fibra óptica se sustituye por un enlace satelital:

Todos los valores quedan igual excepto el retardo de propagación. El valoractualizado de tp. y el RTT resultante son de:

tp = 2× 2× 36, 000

300, 000= 480ms

RTT = tto + ttd + ttw + tpr + tp = 616.99ms

Diseño y Arquitectura de Redes Telemáticas 46

Page 57: Diseño y Arquitectura de Redes Telemáticas

2.4. DESEMPEÑO

Figura 2.3: Principales elementos de retardo en una red satelital

El principal elemento de retardo es el retardo de propagación en el enlaceWAN. Esta red está limitada en latencia. Hay muy poco que la tecnologíapueda hacer para reducir el RTT en este tipo de red.

Caso de estudio: Evaluación de retardo

Los ejemplos anteriores proporcionan un límite inferior del retardo de ida y vuel-ta apreciado entre dos sitios separados una distancia de 900 km. En el presente caso semuestra un estudio real sobre mediciones del retardo observado al consultar un servidorde base de datos a través de distintas redes: LAN, WAN terrestre, satelital dedicado ysatelital compartido.

Las mediciones se hacen con un analizador de protocolos del lado del cliente en unaconfiguración como la mostrada en la figura 2.4.

Figura 2.4: Configuración recomendada para evaluar el retardo de ida y vuelta

Como puede observarse, para este tipo de estudios el RTT se mide en el extremodel cliente (el que iniciará la solicitud). Es importante activar filtros en el analizador demanera que solamente se observe el tráfico entre los equipos involucrados.

Diseño y Arquitectura de Redes Telemáticas 47

Page 58: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

Ambiente de red local

En la primera evaluación, se colocan cliente y servidor en la misma red local. Estopermite configurar y probar la maqueta así como obtener un límite inferior para el tiempode respuesta. La conversación capturada se muestra en la tabla siguiente. La columna delintervalo de tiempo despliega la diferencia entre tramas consecutivas.

No. Tamaño Tiempo Dirección Banderas Contenido1 76 0.000 C → S .AP... Binario2 74 0.010 S → C .AP... Binario

3 253 0.000 C → S .AP... SELECT COUNT (COD CLIENTE) FROM (MGCLIENTES) WHERE (COD CLIENTE) = x

4 139 0.000 S → C .AP... Binario5 79 0.000 C → S .AP... Binario6 140 0.000 S → C .AP... RA-01403 no data found

Si bien desde el punto de vista de la aplicación solamente se está realizando unaoperación sencilla, seis paquetes han sido intercambiados en la consulta.

Con el primer paquete el cliente envía información de control al servidor; 10ms des-pués, el servidor responde. Este retraso puede deberse, por ejemplo, al cambio de contextoen el equipo destino para activar la tarea correspondiente del manejador de base de datos.En el paquete 3, el cliente está enviando los datos correspondientes a la consulta; muy pro-bablemente los paquetes 4 y 5 son acuses de recibo del protocolo de control. Finalmente,la respuesta llega en el paquete 6.

Los intervalos entre todos los demás paquetes son demasiado pequeños para ser cap-turados por el analizador de protocolos. Toda la transacción toma alrededor de 10ms.

Ambiente WAN terrestre

Esta vez, el servidor se encuentra a 900 km de distancia del cliente y los dos sitios seinterconectan por medio de un enlace E0 terrestre basado en fibra óptica. Los resultadosson los siguientes:

No. Tamaño Tiempo Dirección Banderas Contenido1 76 0.000 C → S .AP... Binario2 74 0.090 S → C .AP... Binario

3 252 0.010 C → S .AP... SELECT COUNT (COD CLIENTE) FROM (MGCLIENTES) WHERE (COD CLIENTE) = x

4 139 0.100 S → C .AP... Binario5 79 0.000 C → S .AP... Binario6 140 0.050 S → C .AP... RA-01403 no data found

Se siguen generando seis paquetes en este intercambio, pero los intervalos entrelos paquetes emitidos por el cliente y las respuestas del servidor son considerablemente

Diseño y Arquitectura de Redes Telemáticas 48

Page 59: Diseño y Arquitectura de Redes Telemáticas

2.4. DESEMPEÑO

mayores. Por supuesto, la diferencia se atribuye, sobre todo, al retardo de propagación enla red WAN. Toda la transacción toma ahora alrededor de 250ms.

Ambiente WAN satelital dedicado

Para este escenario, cliente y servidor se interconectan a través de un enlace satelitalSCPC (Single Channel Per Carrier) dedicado únicamente a la comunicación entre los dossitios. Las tramas observadas en este caso son:

No. Tamaño Tiempo Dirección Banderas Contenido1 76 0.000 C → S .AP... Binario2 76 0.800 C → S .AP... Binario3 74 0.850 S → C .AP... Binario

4 253 0.010 C → S .AP... SELECT COUNT (COD CLIENTE) FROM (MGCLIENTES) WHERE (COD CLIENTE) = x

5 64 190 S → C .A... Vacío6 139 0.360 S → C .AP... Binario7 79 0.000 C → S .AP... Binario8 140 0.520 S → C .AP... RA-01403 no data found

La diferencia de tiempos ya es muy notoria. Una consulta que llevó solamente 10mssobre una red de área local y 250ms sobre un enlace terrestre, ahora tarda 2.730 s a travésde este enlace. Estos tiempos ya son más que suficientes para que el usuario note unadiferencia.

Hay dos paquetes de más. El segundo paquete transmitido de la fuente al destino800ms después del primero es muy probablemente una retransmisión del primero al ter-minar el tiempo de espera de la respuesta. El quinto paquete es un acuse de recibo delpaquete así duplicado.

El principal elemento de retardo en este escenario es el retardo de propagación a travésdel enlace satelital. Un aumento en el ancho de banda del enlace, no tendrá ningún impactoapreciable en el retardo percibido.

Considere ahora el escenario “normal” en el que se realizan varias consultas paraobtener la información con la que llena una sola pantalla. Suponiendo que se requieranúnicamente tres consultas y que la respuesta a las mismas no sea muy grande, se requierede casi 9 segundos ¡para llenar una sola pantalla de información!

Ambiente WAN satelital compartido

En este escenario, la conexión cliente-servidor es TDMA (Time Division MultipleAccess) compartido. Antes de poder enviar información, hay que solicitar y esperar laasignación de una ranura de tiempo, lo cual introduce retardos variables. Las tramas ob-servadas en este escenario son:

Diseño y Arquitectura de Redes Telemáticas 49

Page 60: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

No. Tamaño Tiempo Dirección Banderas Contenido1 76 0.000 C → S .AP... Binario2 74 0.608 S → C .AP... Binario

3 254 0.001 C → S .AP... SELECT COUNT (COD CLIENTE) FROM (MGCLIENTES) WHERE (COD CLIENTE) = x

4 58 1.887 S → C .A... Vacío5 139 0.011 S → C .AP... Binario6 79 0.000 C → S .AP... Binario7 140 0.783 S → C .AP... RA-01403 no data found

Efectivamente, hay una variabilidad mayor en las diferencias de retardo observadas.El cuarto paquete, con un retardo diferencial de 1.887 s, es muy probablemente una réplicadel segundo paquete enviado por el servidor dado que el tercer paquete se ha retrasadodemasiado esperando el acceso al canal. El retardo total observado es de 3.29 s.

También es interesante observar algunas gráficas sobre los retardos observados en lostres escenarios.

(a) Enlace terrestre

(b) Enlace satelital dedicado (c) Enlace satelital compartido

Figura 2.5: Retardos medidos en distintos tipos de enlace

En la figura 2.5, se muestra cómo los retardos en un enlace cualquiera pueden in-crementarse considerablemente con respecto al retardo mínimo teórico, o incluso conrespecto al retardo promedio, dependiendo del porcentaje de uso del ancho de banda enun instante cualquiera. Recuerde que el retardo mínimo teórico en el enlace terrestre es de144ms y en la figura (a) se observa cómo los picos de retardo pueden alcanzar los 2 s con

Diseño y Arquitectura de Redes Telemáticas 50

Page 61: Diseño y Arquitectura de Redes Telemáticas

2.5. SEGURIDAD

relativa facilidad, y en casos extremos pueden llegar a más de 7 s. Se logra percibir unavariabilidad en el retraso a lo largo del tiempo, que puede coincidir con las actividadesdurante la jornada laboral.

En los datos obtenidos del canal satelital dedicado y que aparecen en la figura 2.5(b), se muestra un retardo medio mayor que en el enlace terrestre debido a la latencia.También se alcanza a distinguir una mayor variabilidad, pero se considera razonable.

Los datos recabados para el enlace satelital compartido se presentan en la figura 2.5(c). El retardo medio es mucho mayor, pero lo que es más evidente es su enorme variabili-dad a lo largo del periodo evaluado. En este tipo de enlaces es muy difícil ofrecer serviciosinteractivos y francamente improbable servicios de tiempo real.

2.5. Seguridad

La seguridad es uno de los aspectos más importantes en el diseño de la red, sobretodo si se contempla que ésta tenga acceso a Internet o a Extranets y debe ser tomada enconsideración desde las primeras fases de diseño. El objetivo es buscar garantías de que eldiseño ofrece alguna protección contra pérdida o daño de datos y recursos. Los incidentesde seguridad no deben afectar la capacidad de operación de las empresas.

Los objetivos de seguridad pueden entrar en conflicto con otros requerimientos comocosto, facilidad de uso, redundancia y escalabilidad. Considérese, por ejemplo, el caso enel que toda la información debe pasar por un único punto para ser cifrada/descifrada, loque puede provocar cuellos de botella y representa un punto de falla.

Cuando se desea aplicar una política eficaz de seguridad, se debe involucrar profun-damente a los empleados. Estudios recientes indican que entre los principales problemasde seguridad en las empresas destacan los virus introducidos por empleados al instalarsoftware indebido, los errores humanos, y los actos de vandalismo por empleados des-contentos. El tema de seguridad se estudiará con mayor detalle en el capítulo 4.

2.6. Administración

Otro elemento que debe considerarse desde las primeras etapas de diseño es la admi-nistración de la red. Como se presenta en el capítulo 5, una red bien administrada traegrandes beneficios para la organización. Si el cliente ya cuenta con políticas de adminis-tración, puede conocer con precisión cuáles son sus requerimientos de administración. Encaso contrario, la terminología propuesta por el modelo OSI puede servir como punto deentrada para tratar de identificar sus necesidades.

El modelo de OSI divide el problema de gestión en cinco subsistemas, los cuales sepresentan a continuación en el orden en el que típicamente son atendidos por las empresas:

Gestión de fallas. Tiene por objetivo detectar, aislar y corregir problemas, reportarlos ydarles seguimiento.

Diseño y Arquitectura de Redes Telemáticas 51

Page 62: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

Gestión de configuración. Orientada a controlar, identificar, colectar información y do-cumentar los objetos administrados (hardware, software, cuentas de usuarios, etc.).

Gestión de desempeño. Su función es satisfacer los acuerdos de nivel de servicio (Ser-vice Level Agreement, SLA) de manera eficiente, y prever planes de expansión.

Gestión de seguridad. Busca monitorear y evaluar las políticas de seguridad, adminis-trar llaves y contraseñas, etc.

Gestión de la contabilidad. Este subsistema pretende identificar quién utiliza los recur-sos, cuánto y para qué. Útil también para planear cambios de capacidad.

2.7. Facilidad de uso

Este requerimiento está muy relacionado con los requerimientos de administración ydepende de la experiencia del personal responsable de la red y de los usuarios. Buscasimplificar en lo posible que la red sea transparente al usuario final a través de meca-nismos como servidores de configuración automática (por ejemplo, DHCP), políticas deasignación de nombres, sistemas de seguridad basados en biometría, etc.

2.8. Adaptabilidad

Un buen diseño de red debe facilitar la adaptación a nuevas tecnologías y cambios en laoperación. La red es una entidad inmersa en un ambiente de continuas transformaciones.Durante el análisis de la red, debe quedar claro si no se contemplan cambios en el corto ymediano plazo en aspectos como:

Protocolos de red;

topologías de interconexión;

prácticas de negocio;

flujo de datos, patrones de tráfico;

requerimientos de calidad de servicio.

La mejor recomendación es seguir un diseño modular y basado en estándares. Debenevitarse soluciones novedosas basadas en equipos propietarios que no han sido probadoslo suficiente, o de proveedores cuya solvencia no esté garantizada.

Diseño y Arquitectura de Redes Telemáticas 52

Page 63: Diseño y Arquitectura de Redes Telemáticas

2.9. COSTO-BENEFICIO

2.9. Costo-beneficio

Es más un requerimiento de negocios que técnico, pero está muy relacionado con lasdecisiones tomadas para los requerimientos técnicos. Por ejemplo, si la disponibilidad esprioritaria, será necesario invertir en equipos altamente fiables y proporcionar cierto nivelde redundancia en la red. En el capítulo 5 se presentarán algunas de las métricas que seutilizan para evaluar la factibilidad de un proyecto de TI.

El objetivo del diseño debe ser transportar la máxima cantidad de información satis-faciendo los requerimientos identificados, a un costo financiero dado. El costo financieroincluye tanto el costo de los equipos como los costos recurrentes de operación (pago delicencias, renta de enlaces, etc.).

En muchas ocasiones, el mayor costo operativo de la red ha sido la renta de enlacesWAN con circuitos privados, por lo que los primeros esfuerzos para maximizar el cos-to/beneficio se concentrarán en esa dirección. Por ejemplo, es posible utilizar ingenieríade tráfico y enrutamiento con restricciones para minimizar el tráfico que circula por es-tos enlaces. También se pueden combinar servicios de voz y datos en un mismo enlace,implementando mecanismos de QoS si es necesario.

Otro costo muy elevado en la operación de la red suele ser la capacitación, entrena-miento y nómina del personal involucrado en su gestión. Estos costos pueden reducirseproporcionando un diseño claro y modular de la red, y simplificando y automatizando lastareas de configuración y administración de los equipos.

2.10. Conflictos entre requerimientos

Como se ha mencionado, algunos de los requerimientos técnicos entran en conflictoentre sí. Para resolver estos conflictos, es importante definir con el cliente cuál el reque-rimiento más relevante y hacerlo un elemento central del diseño. De manera similar, sedeben asignar pesos a los otros requerimientos en función de los criterios del cliente.

A veces la asignación de prioridades es mucho más compleja pues diferentes áreasdentro de la misma organización pueden tener distintas prioridades; en cualquier caso, esnecesario documentarlas y tratar de establecer compromisos entre ellas.

2.11. Problemas

2.1. En el dimensionamiento de una red, tradicionalmente se consideraba el prin-cipio de localidad que sigue una distribución Pareto: 80 % del tráfico generado enun determinado segmento (o subred), se mantiene en ese segmento y sólo el 20 %restante debe ser encaminado a otros segmentos (o subredes). ¿Por qué hoy se cues-tiona la validez de este principio?

Diseño y Arquitectura de Redes Telemáticas 53

Page 64: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

2.2. De acuerdo a la ley de Moore, la capacidad de procesamiento de los equiposelectrónicos se duplica cada 18 meses. ¿De qué manera esta ley puede afectar elanálisis de requerimientos para diseñar una red de comunicaciones?

2.3. Defina disponibilidad y confiabilidad en términos de MTBF y MTTR.

2.4. ¿Cuáles son los principales elementos que influyen en determinar un valor deMTTR para un sistema?

2.5. ¿Cuál es la disponibilidad de un equipo de red que anuncia un MTBF de 6, 000hry se supone que el proveedor garantiza un MTTR de 4hr?

2.6. En una red telefónica pública, el objetivo de disponibilidad (sin contar la redde acceso), es de 99.999 % (“the five nines”).

(a) ¿A cuántos minutos de fallos al año corresponde este valor?

(b) Para la red de acceso, el objetivo es de 99.95 % y el compromiso es dereparar un fallo en cuatro horas. ¿Cuántos fallos por año pueden soportarse?

2.7. Cierto sistema está compuesto por tres elementos A,B,C dispuestos comoen la figura de la izquierda. Sus MTBFson de 5, 000, 10, 000 y 15, 000 horas. Porrazones de logística, el MTTR de los tres es de 24 horas.

(a) ¿Cuál es la disponibilidad del sistema? Aproxime a seis cifras.

(b) ¿Cuál es la disponibilidad si el sistema se modifica como en la figura de laderecha?

A B C

A

A

B

B

C

2.8. Cierta empresa ha estimado que un minuto de caída en su red le representa unapérdida de $500.00. ¿Cuánto dinero pierde al año si:

(a) La disponibilidad es de 99.9 %?

(b) La disponibilidad es de 99.99 %?

(c) ¿Cuál es la disponibilidad que debe tener si no puede perder más de $30, 000.00al año?

2.9. ¿Qué es una aplicación de misión crítica? ¿Cuál es un requerimiento típico dedisponibilidad para estas aplicaciones?

2.10.

(a) ¿Qué tipo de fallos se toman en cuenta al estimar la confiabilidad de unPBX?

Diseño y Arquitectura de Redes Telemáticas 54

Page 65: Diseño y Arquitectura de Redes Telemáticas

2.11. PROBLEMAS

(b) ¿La disponibilidad de 99.999 %, se refiere a: (i) El servicio residencial;(ii) El servicio comercial; (iii) El servicio de larga distancia; (iv) Las líneastroncales; (v) El conmutador en la central;(vi) todo?

2.11. Calcule la ocupación promedio del área de almacenamiento temporal de unmultiplexor estadístico modelado como una cola M/M/1 para los siguientes casos:

(a) Diez terminales conectadas. Cada una genera, en promedio, paquetes conlongitud de 960 bits con distribución exponencial cada 8 s. La línea de salidaes de 2, 400 b/s.

(b) La generación de paquetes cambia a un paquete cada 5 s en promedio.

(c) Repita el punto (a) conectando 16 terminales.

2.12. Si se aumenta la capacidad de almacenamiento de los equipos de enrutamien-to y conmutación, puede aumentarse el throughput de la red. ¿Qué consecuenciastendría este razonamiento?

2.13. Un sistema satelital geoestacionario con una tasa de transferencia de 64 kb/sse usa para enviar mensajes de 512 bytes. Suponiendo que no hay errores e igno-rando encabezados, ¿cuál es el máximo throughput si se utilizan ventas de controlde flujo de:

(a) 1 paquete

(b) 15 paquetes

(c) 127 paquetes

2.14. Para un enrutador que es capaz de conmutar paquetes a máxima velocidad(wire-speed) en sus 30 puertos 10Base T .

(a) ¿Cuál es su velocidad de conmutación en paquetes/s si el tamaño de lospaquetes es de 64 bytes? (No olvide considerar el preámbulo –8 bytes– y laseparación entre tramas –12 bytes)

(b) ¿Si los paquetes son de 1, 500 bytes?

2.15. Para un switch FastEthernet,

(a) ¿Cuál es el throughput máximo en paquetes/s considerando un tamaño depaquete de 1, 518 bytes?

(b) ¿Cuál es la eficiencia del enlace de salida si las tramas son enviadas awire-speed?

2.16. ¿De qué manera el tamaño del paquete (MSS) afecta la eficiencia de la red?

Diseño y Arquitectura de Redes Telemáticas 55

Page 66: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

A menor tamaño, más paquetes circulan en la red, por lo que aumenta laeficiencia.A mayor tamaño, aumenta el ancho de banda utilizado, por lo que au-menta la eficiencia.A menor tamaño, menor es la carga útil, por lo que disminuye la eficien-cia.A mayor tamaño, mayor inequidad, por lo que disminuye la eficiencia.

2.17. Mencione dos razones por las que es deseable limitar el tamaño de las colasen los equipos de interconexión en redes TCP/IP.

2.18.

(a) Considere una aplicación que transmite voz sobre IP. La frecuencia má-xima de la señal se corta a 4 kHz y es digitalizada utilizando PCM con 8bits por muestra. Cada paquete contiene 30ms de audio y es transmitido conRTP/UDP/IP (= 40 bytes de encabezado).

i. ¿Cuál es la carga útil de los paquetes?ii. ¿Cuál es la eficiencia de la transmisión?

iii. ¿Cuál es el ancho de banda requerido?

(b) Si la aplicación utiliza ahora un códec G.723.1 (6.4 kb/s),i. ¿Cuál es la carga útil de los paquetes?

ii. ¿Cuál es la eficiencia de la transmisión?iii. ¿Cuál es el ancho de banda requerido?

2.19. Al medir en un analizador de protocolos el flujo de una conversación VoIP queutiliza RTP/UDP/IP (40 bytes de encabezado), se observa que consume un anchode banda de 40 kb/s y que genera 100 paquetes por segundo.

(a) ¿Cuál es la tasa del códec?

(b) ¿Cuál es la eficiencia?

2.20. Llene en la siguiente tabla el ancho de banda requerido en cada caso

IPv4 IPv6

25ms 40ms 25ms 40ms

G.726

(32 kb/s)

G.723

(6.4 kb/s)

2.21.

Diseño y Arquitectura de Redes Telemáticas 56

Page 67: Diseño y Arquitectura de Redes Telemáticas

2.11. PROBLEMAS

(a) Encuentre el retardo de ida y vuelta mínimo para la red que se muestra enla figura sabiendo que:

i) la tecnología de red local es FastEthernet en ambos extremos;ii) el enlace WAN es de 256 kb/s y cubre una distancia de 1, 000 km;

iii) el retardo de conmutación es de 10µs;iv) no hay congestión en ninguno de los segmentos indicados, se envía una

trama de 2 kB al destino y éste responde con un acuse de recibo de 64bytes.

(b) ¿Esta red está limitada en ancho de banda o en latencia? Explique.

2.22. ¿Cuáles son los pasos a seguir para analizar la latencia de un enlace?

2.23. Se desea transmitir un archivo de 512 kB entre dos ciudades separadas 1, 000 kma través de i) un enlace E1 (2.048Mb/s) y ii) un enlace de 1.12Gb/s.

(a) ¿Cuál es el retardo de propagación en cada caso?

(b) ¿Cuál es el retardo de transmisión en cada caso?

(c) ¿Cuál de las dos redes está limitada en latencia? Explique.

(d) Suponga que se tienen cuatro enlaces E1 entre las dos ciudades y que setransmite en paralelo una cuarta parte del archivo por cada enlace. ¿En cuántotiempo se transmite todo el archivo en este caso?

2.24. Una imagen con resolución de 640 × 480 y 3 bytes por píxel debe ser trans-mitida entre dos puntos separados a 250 km. Antes de su transmisión, la imagense procesa por un compresor que reduce su tamaño, en promedio, 10:1. Se utilizaUDP/IPv4 (28 bytes) como medio de transporte, en paquetes de 1 500 bytes y setransmiten todos los paquetes uno tras otro (no hay problemas de control de flujo)¿cuánto tiempo tarda en transmitirse la imagen en:

(a) POTS a 56 kb/s

(b) Cable a 512 kb/s

(c) Un enlace a 2 Mb/s?

2.25. Derive y explique el factor a que relaciona: V , la capacidad del enlace; L, ladistancia recorrida; b, el tamaño medio del paquete; y k, una constante del tiempode propagación en un kilómetro. ¿Cuál es el valor del factor en una LAN? ¿En unenlace de 1Gb/s de 1, 000 km?

Diseño y Arquitectura de Redes Telemáticas 57

Page 68: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 2. REQUERIMIENTOS TÉCNICOS

2.26. Se envía información con un protocolo de ventanas deslizantes por un enlacede 622Mb/s. El tamaño de la ventana de transmisión es de 24 kB y la distanciaentre transmisor y receptor es de 1, 000 km. La velocidad de propagación en elmedio es de 200, 000 km/s.

(a) ¿Cuál es el retardo de propagación?

(b) ¿Cuál es el retardo de transmisión?

(c) ¿Cuál es el throughput maximo (en Mb/s)?

(d) ¿Cuál es la eficiencia del enlace?

Diseño y Arquitectura de Redes Telemáticas 58

Page 69: Diseño y Arquitectura de Redes Telemáticas

Capítulo 3

Caracterización de la red y del tráficogenerado por las aplicaciones

Con mucha frecuencia un proyecto de diseño de redes está orientado a la evolucióno crecimiento de una infraestructura ya existente, y rara vez hacia la creación de unared completamente nueva. Por esta razón, es muy importante iniciar el proyecto con unestudio detallado de las características de la red existente y del tráfico que circula por ella.

Este estudio permitirá identificar si los objetivos de diseño son realistas, se pueden de-tectar cuellos de botella existentes o potenciales y se podrá garantizar la interoperabilidaddel diseño con la infraestructura actual. Además, dará una referencia de base (baseline)contra la cual sea posible evaluar el desempeño del sistema una vez implementado.

A pesar de estas ventajas, la caracterización de la red suele hacerse de manera incom-pleta o superficial argumentando falta de tiempo o suponiendo que la red es bien cono-cida. A menos de que la organización que administra la red haya hecho una muy buenalabor de caracterización, definición de procedimientos y sea sumamente disciplinada enla documentación de los diversos tipos de cambios que se pueden realizar en dispositivos,topología, servicios, etc., la realidad es que un buen análisis en la fase de planeación delmodelo de proceso es indispensable.

Habiendo dicho esto, se habrá de reconocer que la necesidad de terminar lo antesposible con el proyecto puede ser la consecuencia de necesidades de negocio reales yjustificadas. Un buen administrador del proyecto debe poder negociar un balance de prio-ridades y empujar la implementación de algunos servicios, localidades o dispositivos paraversiones futuras de la red, y definir la forma de trabajo más eficiente posible para acortartiempos sin perder calidad. Sea cual sea el camino, en la gran mayoría de los proyectosen donde estos pasos se omiten o se recortan demasiado, el resultado es que el tiempoganado con las omisiones, se perderá con creces en las fases finales del proyecto.

La caracterización de la red implica identificar claramente su topología, los reposito-rios y consumidores de información, los volúmenes de tráfico que son intercambiados yla estructura protocolaria para lograrlo.

Page 70: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

3.1. Caracterización de la topología

La caracterización de la topología empieza por la obtención de un mapa de la red quedescriba su configuración física y lógica, pero abarca mucho más que eso: se deben ob-tener y documentar las políticas de asignación de nombres y direcciones y el esquema dedireccionamiento actualmente utilizado. También se habrá de observar el tipo y estado queguardan los esquemas de cableado y si existen restricciones (ambientales, arquitectónicas,legales) para instalar alguna infraestructura de capa física.

Mucha de esta información fue recabada en la fase de visión y alcance. Durante lafase de planeación, se recaba la información adicional necesaria para completar la carac-terización de la red.

La información recabada debe ser examinada y validada tratando de asegurar que nose han hecho cambios importantes no documentados. Partir de suposiciones erróneases un grave riesgo que puede comprometer seriamente el éxito del proyecto.

3.1.1. Mapa de la red

El mapa de la red comienza por un conjunto de esquemas de interconexión con dife-rentes niveles de abstracción en donde se presenta la organización topológica de la red.Existen diversas herramientas que permiten automatizar la construcción y/o validación deestos esquemas.

Al integrar el mapa de la red, se debe crear un documento lo más completo posible enel que se especifique, cuando corresponda:

la ubicación física de las instalaciones: ciudad, edificio, piso y, en algunos casos,hasta cubículo donde se encuentren los equipos principales (nodos de conmutación,servidores, etc.);

el personal responsable de los diferentes elementos de la red;

los enlaces WAN entre ciudades especificando tecnología, capacidad y restriccio-nes;

los enlaces CAN y LAN entre edificios especificando igualmente la tecnología uti-lizada, sus capacidades y restricciones.

los puntos de acceso al proveedor de acceso a Internet y los servicios contratados;

los servidores de acceso remoto y de VPNs, y las políticas de acceso;

las políticas y procedimientos de seguridad;

las políticas y procedimientos de administración;

la estructura lógica de la red.

Diseño y Arquitectura de Redes Telemáticas 60

Page 71: Diseño y Arquitectura de Redes Telemáticas

3.1. CARACTERIZACIÓN DE LA TOPOLOGÍA

Caso de estudio.- Topología física y topología lógica

En una empresa de servicios con cobertura nacional, el servicio de correo en-frentaba serios problemas de rendimiento, pero extrañamente, parecían afec-tar solamente la comunicación entre algunas ciudades. Por ejemplo, la ciudadF en la figura 3.1 podía tener problemas de comunicación con la ciudades G,I y J , pero no con las demás. Algunas ciudades no tenían problema alguno.

Al estudiar las condiciones de la organización, se encontraron dos elementosinteresantes. En primer término, el departamento responsable de administrarel servicio de correo electrónico no era el mismo que se hacía cargo de laadministración de los enlaces de comunicación entre las diferentes ciudades,tampoco reportaban al mismo jefe, y en realidad tenían poca comunicaciónentre sí. En segundo lugar, la topología de la red de correo electrónico (topo-logía lógica) era una estrella simbolizada por las líneas rectas de la figura 3.1:todos los servidores de correo electrónico avanzaban el correo para otras ciu-dades a las oficinas centrales en la ciudad A, y un servidor central ahí loredistribuía hacia las ciudades destino.

Figura 3.1: Topología física y lógica de un servidor de correo

Por su parte, los enlaces (topología física), representados por las líneas que-bradas en la figura, mostraban la topología de estrellas interconectadas a tra-vés del triangulo A, E, H . Al enviar un mensaje de correo electrónico de laciudad F a la ciudad G, el servicio de correo electrónico asumía una topo-logía con una única estrella y lo enviaba a la ciudad A, para que de ahí elmensaje fuera enviado a la ciudad G.

Dada la topología física de los enlaces, el mensaje salía de F hacia E, deahí viajaba a A, hasta llegar al servidor distribuidor de correo electrónico,quien entonces lo enviaba de vuelta sobre el mismo enlace entre A y E, y deahí viajaba hasta G. El mensaje recorría entonces cuatro segmentos de red,

Diseño y Arquitectura de Redes Telemáticas 61

Page 72: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

cuando idealmente solo necesitaba recorrer dos, y los dos viajes de sobra sedaban sobre un mismo segmento de red.

Una vez identificado el problema, se reconfiguraron los servidores de correolocales para ofrecer un servicio distribuido coherente con la arquitectura dela red.

3.1.2. Asignación de nombres y direcciones

Conocer el esquema de asignación de nombres nos permitirá acotar la solución dediseño de red. El esquema de direccionamiento puede afectar el diseño propuesto parasatisfacer los requerimientos técnicos. Por ejemplo, puede ser necesario el uso de traduc-tores de direcciones (NAT, Network Adress Translation) o el renunciar a sumarización derutas si los protocolos actualmente utilizados no soportan este esquema1.

Durante la caracterización de la red es necesario distinguir cuáles son las prácticascomunes para asignar nombres a dispositivos y servicios. También deberá quedar clara laestrategia de asignación de direcciones. Por ejemplo, deberá tenerse una respuesta clara alas siguientes preguntas:

¿Se sigue o promueve un modelo de direccionamiento jerárquico? ¿Se utiliza opuede utilizarse la sumarización de direcciones?

¿Se utiliza o puede utilizarse una estrategia de asignación dinámica de direcciones?

¿Se cuenta con un rango de direcciones libre suficiente para los objetivos de diseño?¿Se debe negociar un bloque de direcciones?

¿Se utiliza o puede proponerse un esquema de direccionamiento privado?

3.1.3. Caracterización de los medios de transmisión

Es imprescindible realizar este estudio para poder satisfacer los requerimientos deescalabilidad y disponibilidad. Al recabar información referente a los medios de trans-misión, es decir, a la capa física del modelo de OSI, se deben identificar las tecnologíasutilizadas tanto en la red local como en las interconexiones MAN y WAN. También sedebe identificar la ubicación y estado de los puntos de conexión: paneles de parcheo, cló-set de alambrado, puntos de cruce de cableado vertical y horizontal, etcétera. Para unared CAN, Campus Area Network), debe señalarse claramente cuál es la tecnología deinterconexión entre edificios y cuál es la distancia que los separa.

La experiencia indica que se es más informal al desplegar una red local, por lo quees ahí donde se sugiere que se ponga mayor énfasis en la caracterización. Al detectar eltipo de cableado y/o de red inalámbrica que se utiliza, se pueden identificar problemaspotenciales al diseño propuesto.

1Estos temas serán tratados con mayor detalle en el capítulo 4.

Diseño y Arquitectura de Redes Telemáticas 62

Page 73: Diseño y Arquitectura de Redes Telemáticas

3.1. CARACTERIZACIÓN DE LA TOPOLOGÍA

En lo que concierne al cableado de la red, se deberá detectar si se siguen correctamentelas normas de cableado estructurado; si la categoría de cables, rosetas, conectores, etc. escompatible con la velocidad de transmisión deseada; si se respetan las distancias máximas,los códigos de color para los conectores; etc.

Se deberá verificar cuántos pares de cable están siendo utilizados y en qué estado seencuentran. Por supuesto, también deberá documentarse la cantidad de pares disponiblesy en qué áreas se encuentran. Además, se debe verificar que la ductería tiene espaciosuficiente para introducir más cable de ser necesario.

Un ducto de par trenzado nunca debe estar ocupado a más del 50 % de su capacidad.

Si se utilizan redes inalámbricas, se debe verificar que las tarjetas de red y los puntosde acceso están homologados a las normas mexicanas. Así mismo, es necesario verificarque los puntos de acceso están configurados correctamente, que no interfieren entre sí yque el radio de cobertura satisface los nuevos requerimientos.

3.1.4. Restricciones ambientales y arquitectónicas

Durante el recorrido de las instalaciones se debe prestar mucha atención al entornoen el que éstas se ubican con el fin de identificar riesgos que pudieran comprometer se-riamente la viabilidad del proyecto en etapas posteriores. Por ejemplo, si el edificio seencuentra en una zona con riesgos de inundaciones (alta precipitación pluvial, cercanoa un río o laguna), se debe buscar que los nodos de interconexión (y en general, el cen-tro de cómputo) se ubiquen al menos en el primer piso. De hecho, esta es una prácticarecomendada para la seguridad física de las instalaciones de TI.

Si la instalación se encuentra en una zona de vibraciones anormalmente altas (porlas características de la empresa, por encontrarse muy cerca de una vía de ferrocarril,etcétera.), el tipo de conector a utilizar debe ser más robusto. Así mismo, se deben preverrevisiones frecuentes de las condiciones del cableado.

Es posible que el edificio sea rentado o que sea de interés histórico y esté protegidopor leyes especiales. En estos casos, será importante garantizar que se cuenta con lospermisos necesarios para instalar la infraestructura de red necesaria (perforaciones parainstalar cableado en red local, obra civil para instalar antenas, etcétera.)

Para interconectar dos edificios, aún si están relativamente cercanos, se debe contarcon permiso de vía. Si se piensa utilizar algún medio inalámbrico (los enlaces láser suelenser una excelente opción) se debe verificar que se cuenta con línea de vista y que no hayrazones para suponer que ésta va a perderse en el mediano plazo.

También es conveniente identificar y registrar que se cuenta con las condiciones ade-cuadas de ventilación, control de temperatura, suministro de energía eléctrica regulada yfuentes de poder no interrumpible (UPS).

Se debe prestar una atención particular a ambientes extremos. Por ejemplo, en ciuda-des con muy altos niveles de humedad y temperatura, equipos convencionales de interco-nexión pueden no funcionar correctamente si no se cuenta con una instalación ambiental

Diseño y Arquitectura de Redes Telemáticas 63

Page 74: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

apropiada. De forma similar, en naves industriales con maquinaria eléctrica pesada, lasinducciones electromagnéticas pueden afectar severamente las transmisiones en cablesno blindados.

Caso de estudio.- En una empresa financiera, se decidió instalar equipos deaire acondicionado. Para no alterar la arquitectura del edificio, se determinócolocar los equipos en los clósets de cableado, encima de los concentradoresy enrutadores de la red. Una tarde de invierno, algún empleado consideróconveniente apagar los equipos de aire acondicionado pues la temperaturano justificaba su utilización. Al condensarse el líquido de estos equipos, éstecayó hacia los equipos de interconexión, los cuales, naturalmente, dejaron defuncionar.

3.2. Desempeño de la red actual

Evaluar el desempeño de la red actual es fundamental para establecer una referenciaa partir de la cual se puedan comparar las prestaciones del nuevo diseño. Esta evalua-ción también permite identificar potenciales cuellos de botella y puntos críticos dondehabrá que prestar atención especial al diseño.

La evaluación del desempeño de una red puede realizarse a través de modelos analíti-cos, de simulación y mediante mediciones directas. En esta sección se plantea brevementeesta última opción y las técnicas de modelado se presentarán en el capítulo 7.

Para colectar información sobre el estado de la red y sus equipos, se medirán variablesy parámetros de desempeño de la red, lo cual suele ser un proceso largo y complejo. Hayque decidir lo más pronto posible cuáles son las variables a estudiar, el tipo de herramien-ta a utilizar, la duración del experimento y sobre qué puntos de la red llevarla a cabo. Paratodos estos elementos no hay una respuesta única, pues dependen completamente de losobjetivos del estudio.

En cuanto a los puntos de evaluación, los primeros candidatos son los segmentos en lared dorsal y aquellos por donde corren los flujos de misión crítica, así como los segmentosque interactuarán con el nuevo diseño.

3.2.1. Herramientas de recolección

Existen diversas herramientas que nos permiten obtener distintos parámetros de desem-peño, y con distintos niveles de detalle.

Es muy importante conocer la utilidad y las características (sus capacidades y nichosde aplicación) de las herramientas a nuestra disposición pues el éxito del estudio de-penderá de la selección de la herramienta apropiada.

Diseño y Arquitectura de Redes Telemáticas 64

Page 75: Diseño y Arquitectura de Redes Telemáticas

3.2. DESEMPEÑO DE LA RED ACTUAL

Entre las herramientas típicas para realizar estudios de evaluación de desempeño seencuentran los monitores y analizadores de protocolos, los agentes y protocolos de ad-ministración (estudiados en el capítulo 4), las bitácoras y guiones de administración ensistemas operativos y las sondas especializadas tanto activas (que introducen un flujo deevaluación en la red) como pasivas.

Hoy en día es posible encontrar herramientas de monitoreo muy sofisticadas, que in-corporan agentes inteligentes para apoyar al administrador de la red a detectar posiblesproblemas en la red y proponerle alternativas de solución. Dicho esto, sigue siendo deprimordial importancia el saber interpretar adecuadamente la información que estas he-rramientas ofrecen. Por ejemplo, al analizar una gráfica de porcentaje de utilización comola que se muestra en la figura 3.2, es importante considerar que los analizadores de pro-tocolos muestran la carga transportada en algún segmento de la red, la cual puede serdistinta a la carga ofrecida a la red.

Figura 3.2: Una vista típica de un analizador de protocolos en el que se observa la utili-zación del segmento, posibles indicadores de congestión, y la distribución algunas de lascaracterísticas de los protocolos observados

También se debe tener alguna idea de lo que se está buscando o de lo que se esperaobservar en el estudio. Por ejemplo, la figura 3.3 muestra otra pantalla del analizadoren el que se reporta cómo se distribuye la capacidad del segmento utilizada entre losdistintos protocolos detectados, junto con otras estadísticas de utilización (cantidad debytes y de tramas medidos, número de tramas en difusión, errores detectados, etcétera.).Más adelante en este capítulo se presentan algunas cifras de lo que se considera una red“saludable”.

Este tipo de gráfica permite detectar si hay protocolos que no deberían en principiotransitar en la red, si existen protocolos que envían demasiadas tramas de difusión, cuálesson las aplicaciones/protocolos más utilizados, etcétera.

Los monitores y analizadores de protocolos se instalan en el segmento de red de interés

Diseño y Arquitectura de Redes Telemáticas 65

Page 76: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

Figura 3.3: Otra vista del analizador de protocolos que permite conocer la distribuciónde cómo se está utilizando la red

y recaban información de los flujos observados. Esto significa que para tener una ideaglobal de la red, habría que colocar un analizador en cada uno de los segmentos de interésy correr el monitoreo durante el tiempo “suficiente”. En ciertos casos es necesario hacerel estudio de esta manera, pero la mayoría de las veces, es suficiente incorporar agentesde monitoreo en los mismos dispositivos de red (las sondas RMON) que se incorporan alsistema de administración de red, como se verá en el capítulo 4.

3.2.2. Periodo y frecuencia de recolección

En un estudio de evaluación de desempeño, frecuentemente los parámetros de interésson promedios evaluados en una ventana de tiempo. La selección del intervalo, suduración y la frecuencia de captura de los valores son fundamentales para poder teneruna interpretación adecuada los resultados obtenidos.

Consideremos, por ejemplo, que se desea evaluar la red en condiciones de carga nor-mal, pero el muestreo se hace durante un período atípico (a la hora de entrada, muchosempleados encienden su computadora y se generan muchos mensajes de difusión DHCP;en fin de mes o al cierre del ciclo, cuando hay picos de operación; etcétera.). Entonces, setendrá una imagen distorsionada del tráfico y se tenderá a sobredimensionar la red.

En otras ocasiones, son precisamente los picos de tráfico los eventos de interés y esdonde se deberán realizar mediciones especialmente detalladas. Dependiendo del giro dela empresa, se deberá tener una idea de la forma en que la utilización variará. Por ejemplo,es común que el tráfico en la red se incrementa al llegar el fin de mes o el cierre del año odel periodo fiscal. El incremento de tráfico en estos periodos puede ser considerable y es

Diseño y Arquitectura de Redes Telemáticas 66

Page 77: Diseño y Arquitectura de Redes Telemáticas

3.2. DESEMPEÑO DE LA RED ACTUAL

muy importante que la red esté en condiciones de proporcionar un servicio apropiado enestos periodos críticos.

Para poder diseñar e interpretar correctamente este tipo de estudios, también es im-portante conocer las características de operación dentro de la organización. Por ejemplo,se detectarán picos hacia el servidor de correo si en las mañanas los empleados entranmás o menos a la misma hora y suelen revisar y responder a sus mensajes. En ciertasorganizaciones se detectan picos similares inmediatamente antes del almuerzo y del finde la jornada pues la política organizacional es tratar de evitar dejar asuntos. Algunas em-presas hacen un uso intensivo de su red WAN en horas no hábiles para consolidar basesde datos y distribuir respaldos. En esos casos, es necesario determinar si deben realizarsemediciones detalladas durante este periodo.

Con esta información y habiendo identificado claramente el objetivo del estudio, seprocede a diseñar el mecanismo de recolección. El periodo deberá ser suficientementelargo para ser significativo; idealmente, deberá cubrir un ciclo completo de operación delcomportamiento a evaluar.

La evaluación deberá realizarse sobre una población (nodos, enlaces, aplicaciones)representativa. La selección de los segmentos debe comenzar obviamente por aquellos enlos que se ubican servidores importantes y los segmentos en donde hay grupos grandes deusuarios, tanto como los segmentos por donde habrá de fluir el tráfico en el camino de unsitio al otro.

La frecuencia de recolección, es decir, la intensidad con la que se evalúan las métri-cas de interés, establece un compromiso entre el nivel de detalle deseado y la cantidadde información a almacenar y procesar. La decisión adecuada se tomará en función delobjetivo del estudio:

Muestreando en el orden de segundos, se pueden detectar problemas a nivel pro-tocolos de comunicación: retransmisiones por temporizadores mal configurados,tormentas de difusión, enrutadores que publican rutas demasiado frecuentemente,etcétera.

Para poder llevar a cabo un análisis de desempeño y obtener una referencia debase sobre el comportamiento general de la red, suelen realizarse mediciones conintervalos de uno a cinco minutos.

Para identificar patrones globales de utilización, períodos de picos de operación ygráficas de tendencias, muestreos del orden de 5 a diez minutos suelen ser utiliza-dos.

3.2.3. Algunas métricas de desempeño

Dependiendo del tipo de red (LAN, WAN) y de la tecnología utilizada, existen distin-tos parámetros para evaluar la tasa de error observada –y para saber si ésta es aceptable.En todos los casos, es deseable correlacionar la tasa observada contra las métricas decarga y utilización para detectar cuellos de botella o equipo defectuoso en la red.

Diseño y Arquitectura de Redes Telemáticas 67

Page 78: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

Considerando que ethernet es la tecnología dominante en redes locales, a continuaciónse presentan algunas de las métricas comunes de error y sus valores recomendables.

Número de tramas con CRC incorrecto. La recomendación es que no debe haber másde una trama por cada megabyte de información. Se evita definir esta métrica comoun porcentaje del número de tramas para evitar la dependencia con el tamaño de lastramas.

Número de colisiones. En una red que trabaja correctamente, las colisiones detectadasno deberán exceder el 0.1 % de los paquetes emitidos. A primera instancia estopuede parecer extraño dado que las colisiones son el mecanismo natural del controlde acceso en ethernet. Sin embargo, la mayoría de las colisiones se detectan duranteel preámbulo y no son tomadas en cuenta como tramas en colisión.

Porcentaje de paquetes perdidos. En una red bien dimensionada, el porcentaje de pa-quetes perdidos debe ser inferior al 1 %.

Los dispositivos de red y los equipos terminales pueden introducir retardos adicionaleso comportamientos que pueden afectar el desempeño y deben ser tomados en esta fase.Por desgracia, son muchos los factores a considerar y se requiere de mucha experienciapara poder identificarlos. A continuación se mencionan algunos de ellos.

En TCP/IP, los valores por omisión para los buffers de transmisión y recepciónpueden no ser adecuados para la aplicación específica. Por ejemplo, si el espacioreservado para el buffer de recepción es pequeño, el protocolo anunciará una ven-tana de recepción muy pequeña, que limitará el desempeño de la red.

La configuración y la granularidad de los temporizadores también pueden afectar eldesempeño: temporizadores mal configurados y que no se adapten dinámicamentea las condiciones de la red pueden ocasionar retransmisiones de información in-necesarias. La granularidad de los temporizadores en muchas implementaciones deTCP/IP es de 500ms, un valor que puede resultar demasiado grande para reaccionara condiciones de congestión en ciertas implementaciones.

La implementación de las pilas de protocolos en muchos sistemas operativos popu-lares realizan copias de información mientras ésta es transferida de una capa a otra.Estas copias de memoria a memoria pueden degradar el desempeño de los equiposinvolucrados.

El mecanismo de atención a interrupciones de entrada-salida puede ser muy inefi-ciente. Al enviar o recibir tramas por las interfaces de red, los cambios de contextoen los sistemas operativos también pueden introducir retrasos considerables, degra-dando así el desempeño de las aplicaciones.

Debe considerarse que existen varios sistemas complementarios a las aplicaciones dered y que también deben ser tomados en cuenta. Por ejemplo, deberá evaluarse el tiempo

Diseño y Arquitectura de Redes Telemáticas 68

Page 79: Diseño y Arquitectura de Redes Telemáticas

3.2. DESEMPEÑO DE LA RED ACTUAL

de respuesta de los servidores de nombres (DNS) y –aunque su efecto es menor– de losservidores de configuración.

Finalmente, se debe evaluar el desempeño de los nodos de conmutación para identifi-car si ellos representan un posible cuello de botella. En particular, se debe medir la tasade ocupación media en los buffers de salida, la cual debe ser muy baja, y el porcentajede utilización del CPU. De acuerdo a recomendaciones de Cisco, este porcentaje debe sermenor al 75 % en intervalos de muestreo de 5 min.

Al evaluar los nodos de conmutación, se debe verificar que cuentan con los elementosnecesarios para satisfacer los requerimientos de diseño. Por ejemplo, es importante iden-tificar la cantidad de memoria disponible, la versión de sistema operativo y los protocolosde enrutamiento soportados. Podría también ser necesario detectar si el equipo cuentacon los elementos necesarios para dar soporte a los requerimientos de calidad de servicioidentificados.

EJEMPLO 3.1. Si bien es cierto que prácticamente todos los enrutadores ac-tuales soportan el protocolo IPv6, la dominante mayoría lo hace por softwareen la actualidad. El throughput sería muy inferior al conmutar paquetes IPv6comparado con el obtenido para paquetes IPv4, que pueden ser conmutadospor hardware en muchos equipos.

Similarmente, una empresa que desea migrar su red de IPv4 a IPv6 (o permitirla coexistencia de los dos protocolos), debe asegurarse que sus equipos cuen-tan con la capacidad necesaria para aumentar tanto la memoria RAM, dondese almacenan las tablas de enrutamiento (con direcciones mucho mayores),como del firmware, donde se implementan muchas de las funcionalidadesinherentes al nuevo protocolo.

3.2.4. Presentación de resultados

La información recolectada durante un cierto intervalo de tiempo debe ser presentadade manera tal que permita sacar conclusiones útiles. Los datos obtenidos pueden ser pre-sentados en un listado, por medio de una gráfica, o bien mediante un resumen estadísticode los mismos. La representación adecuada depende, una vez más, de los objetivos de laprueba.

Gráficas de tendencia

Una gráfica de tendencia representa la variable de interés contra el tiempo. Es unamanera muy cómoda de visualizar su comportamiento y permite identificar rápidamentesi la variable presenta comportamientos cíclicos, cuándo hay picos, de qué orden son ycuánto duran, etcétera.

Diseño y Arquitectura de Redes Telemáticas 69

Page 80: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

Al capturar la información necesaria para producir las gráficas de tendencia, es posibleentender con mayor claridad el compromiso entre el período y la frecuencia de recolec-ción en función de los objetivos de estudio, discutidos en los párrafos anteriores. Porejemplo, las gráficas de las figuras 3.4 y 3.5, muestran la tasa de salida de un enrutador(en bytes por segundo) en un periodo de un día y de una semana. En la primera gráfica sedesea tener un mayor nivel de detalle, por lo que la frecuencia de captura debe ser mayor.La gráfica de tendencia semanal (figura 3.5) únicamente se utiliza para tener una idea delcomportamiento global de la variable por día. Se puede observar claramente un compor-tamiento cíclico relacionado con la actividad durante las horas hábiles. El hueco largo sinactividad al centro de la gráfica corresponde a un fin de semana con un día festivo.

Figura 3.4: Tasa obtenida (en bytes/s) en la interfaz de salida de un enrutador comercialdurante un día

3.2.5. Análisis estadístico de redes

En general, es imposible determinar con exactitud el valor que tomarán las métricas dedesempeño de interés, por lo que se les suele considerar como variables aleatorias (V.A.)a las que se debe aplicar algún análisis estadístico para poder interpretar correctamentelos resultados obtenidos.

Al considerar las métricas de interés como V.A., se debe obtener un número grande demuestras antes de poder sacar conclusiones sobre ellas. Al agrupar las muestras obtenidasen un histograma que represente la frecuencia de ocurrencia de los valores obtenidos, éstese aproxima a la función de densidad de probabilidad (pdf, probability density function).

La pdf de una variable aleatoria indica qué tan probable es la obtención de cada unode sus valores y contiene todas sus propiedades estadísticas.

Diseño y Arquitectura de Redes Telemáticas 70

Page 81: Diseño y Arquitectura de Redes Telemáticas

3.2. DESEMPEÑO DE LA RED ACTUAL

Figura 3.5: Tasa obtenida (en bytes/s) en la interfaz de salida de un enrutador comericaldurante una semana

Figura 3.6: Histograma que representa la función de densidad de probabilidad de unavariable aleatoria discreta

Diseño y Arquitectura de Redes Telemáticas 71

Page 82: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

En la figura 3.6 se observa una curva con un solo pico o moda. Se trata de una pdfmonomodal. Es bastante común que en redes de comunicaciones se encuentren V.A. convarios picos. Por ejemplo, al graficar el tamaño de las tramas en una red local, típicamentese encontrarán dos picos muy notorios en los valores de 64 y 1,500 bytes. Esto se debeprincipalmente al hecho de que dicho tráfico se compone por lo general de tramas decontrol (acuses de recibo, solicitud de conexión, etcétera.) y tramas de aplicaciones queintercambian grandes volúmenes de información.

Sumarización estadística

Si bien la pdf contiene toda la información estadística de la V.A. de interés, puederesultar muy poco práctica para tomar decisiones, sobre todo cuando se desean hacercomparaciones entre varias V.A. Por ejemplo, al evaluar varias opciones de diseño deacuerdo a su incidencia sobre las métricas como retardo, carga y utilización, será difícilhacer una comparación objetiva al contar únicamente con los histogramas obtenidos paracada caso. Es por estas razones, entre otras, que se busca sumarizar el comportamientode una V.A. en una serie de valores puntuales conocidos como indicadores. Entre losindicadores más utilizados se encuentran los indicadores de tendencia media y los dedispersión.

Indicadores de tendencia media

Los indicadores de tendencia media son la media aritmética o promedio, que se ob-tiene al sumar todos los valores obtenidos entre el número de muestras; la moda, que esel valor más observado, es decir, el obtenido un mayor número de veces; y la mediana,que es el valor justo al 50 % del área bajo la curva de la pdf de la V.A.

EJEMPLO 3.2. Para cierta V.A. se han obtenido las siguientes muestras:

1, 3, 3, 3, 4, 8, 12, 15, 30

N = 9 Σvalores = 79

Media = 799

= 8.7̄ Mediana = valor[5] = 4 Moda = 3

El promedio es el indicador más popular para sumarizar una V.A., pero muchas vecesno es el adecuado. Como se observa en la figura 3.7, en una distribución simétrica, elpromedio, mediana y moda caen en el mismo lugar, pero en una distribución asimétrica nonecesariamente. En el caso de redes de comunicaciones las distribuciones son típicamenteasimétricas.

Si los datos son discretos y pueden ser clasificados, es probable que la moda sea elindicador apropiado. Por ejemplo, considere un enrutador con tres interfaces de salida del

Diseño y Arquitectura de Redes Telemáticas 72

Page 83: Diseño y Arquitectura de Redes Telemáticas

3.2. DESEMPEÑO DE LA RED ACTUAL

Figura 3.7: Indicadores de tendencia media en distribuciones monomodales simétricas yasimétricas

que se desea conocer cuál es la interfaz más utilizada. En este caso, el promedio no tieneningún interés.

Por regla general, el promedio es relevante cuando el valor total de la métrica puedeser de interés, aunque si la pdf está sesgada, la mediana puede ser más representativa puescon frecuencia lo que nos interesa es el indicador de tendencia central.

EJEMPLO 3.3. Para cierto servidor de base de datos, se han obtenido lossiguientes tiempos de respuesta (valores en milisegundos):

20, 20, 20, 30, 40, 50, 60, 60, 70, 80, 940, 950.

La media es de 195ms y la mediana de 55ms. Claramente la mediana esmás representativa de la realidad, pues la distribución está muy sesgada porlas dos transacciones "largas". De hecho, el 83 % de las mediciones está pordebajo del promedio.

Entre los errores más comunes que se cometen al resumir una variable aleatoria a unindicador de tendencia media, está el emplear los promedios sin tener en cuenta sudispersión. Por ejemplo, muy pocas veces es significativo el calcular el promedio devalores notablemente diferentes.

Otro error que se debe evitar al trabajar con promedios es el llamado juego de radios,que se genera al comparar valores divididos con bases distintas, como se muestra en elejemplo siguiente. Desgraciadamente, esta técnica se encuentra con cierta frecuencia enestudios comparativos y benchmarks de productos comerciales.

EJEMPLO 3.4. Para tratar de comparar el desempeño de dos tipos de enruta-dores, A y B, se evalúa el tiempo total de conmutación de cada uno sometidoa dos condiciones de carga distintas, L1 y L2, obteniendo los resultados si-guientes:

Equipo L1 L2 PromedioA 10 s 20 s 15 sB 20 s 10 s 15 s

Diseño y Arquitectura de Redes Telemáticas 73

Page 84: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

Suponiendo que en condiciones de operación la proporción de L1 es similara la de L2, con los promedios obtenidos no hay motivos para preferir un en-rutador sobre el otro. Considere ahora qué sucede si se desea "normalizar"losresultados en relación con el sistema B. La normalización es una práctica co-mún para eliminar las unidades y para restarle importancia al valor absolutode las variables de estudio.

Equipo L1 L2 PromedioA 10/20 = 0.5 s 20/10 = 2 s 1.25 sB 20/20 = 1 s 10/10 = 1 s 1 s

¡Ahora parecería ser que el enrutadorA es 25 % más lento queB! Por supues-to, de haber normalizado con respecto al enrutador A, los resultados seríanexactamente los contrarios.

Indicadores de dispersión

Los indicadores de tendencia media por sí solos pueden dar una información muy li-mitada sobre el comportamiento de la variable de estudio. Estos indicadores deben estarsiempre acompañados de alguno que permita tener una idea sobre la variabilidad que exis-te entre los valores que puede tomar la variable. Estos son los indicadores de dispersión.

Para una distribución unimodal y simétrica, el indicador de dispersión más comúnes la varianza o su raíz cuadrada, la desviación estándar. También se suele utilizar elcoeficiente de varianza, que es la razón entre el promedio y la desviación estándar.

Si la distribución no es simétrica no debería utilizarse la varianza. En caso de que éstaesté acotada, se puede especificar el rango, es decir, los valores máximo y mínimo que lavariable puede tomar. En otro caso, se deben utilizar los percentiles.

Un percentil es el punto en el que el área bajo la curva de la función de distribuciónacumulativa alcanza un cierto porcentaje. Por ejemplo, el percentil 5 % indica que el 5 %de todos los valores obtenidos para la distribución son iguales o menores a ese punto. Estevalor podría ser equivalente en algunos casos al valor mínimo en una distribución acotada.

Los percentiles son de mucha utilidad y comúnmente utilizados pues eliminan losvalores que son atípicos (outliers) y que podrían sesgar indebidamente la distribución.Por ejemplo, si se desea conocer qué interfaces de un enrutador mantienen una utilizaciónalta sostenida es recomendable utilizar percentiles 90 % o 95 %: es casi seguro que todaslas interfaces tuvieron una utilización de 100 % en algún intervalo en que se emitió unaráfaga de datos.

3.3. Caracterización del flujo

Durante la caracterización de la red también es importante obtener un "mapa"de losríos"de información que fluyen por la organización y sus características generales. Esta

Diseño y Arquitectura de Redes Telemáticas 74

Page 85: Diseño y Arquitectura de Redes Telemáticas

3.3. CARACTERIZACIÓN DEL FLUJO

información es de gran utilidad para determinar qué tan adecuada es la infraestructura dered actual y qué modificaciones podrían hacerse para mejorarla.

La caracterización de los flujos implica identificar los repositorios de información, losprincipales usuarios de dicha información, la simetría y características de los intercam-bios, los volúmenes de información intercambiados y las trayectorias recorridas.

Como se mencionó en la sección 2.1, se debe tener presente que el modelo en elque los usuarios en una organización utilizaban mayoritariamente recursos disponibles yadministrados localmente en su área o departamento ha ido desapareciendo gradualmente.

Los repositorios de información (data stores) pueden ser servidores, granjas de servi-dores, mainframes, cintas, lectores de CD, redes de almacenamiento (NAS, SAN), etcéte-ra. Por su parte, los consumidores de información pueden ser redes, subredes o sistemasautónomos.

3.3.1. Tipos de flujo por aplicación

Para poder satisfacer los requerimientos de diseño, es importante identificar las carac-terísticas de los flujos generados por las aplicaciones. Se puede empezar por clasificar lasimetría, direccionalidad y requerimientos de calidad de servicio de los flujos y posterior-mente se tratará de evaluar el volumen del tráfico intercambiado. Como punto de partida,algunos flujos típicos en redes de cómputo tienen las siguientes características:

Terminal virtual - servidor. Asimétrico y bidireccional (ejemplo: telnet)

Cliente - servidor. Asimétrico y bidireccional (ejemplo: sesiones HTTP)

Entre pares. Simétrico y bidireccional (ejemplo: NIS-II, videoconferencia)

Servidor - servidor. Bidireccional y generalmente simétrico (ejemplo: cluster deservidores, respaldo de información)

Cómputo distribuido. Las características dependen de la aplicación particular (ejem-plo: grid computing)

Difusión multimedia. Tráfico unidireccional (ejemplo: podcasts)

La simetría de los flujos debe considerarse en varias dimensiones como por ejemplo,en el volumen de tráfico intercambiado, en la velocidad de los enlaces en cada dirección,y en los requerimientos de QoS.

Algunas tecnologías como ADSL aprovechan las características asimétricas de losflujos cliente-servidor. Sin embargo, se debe tener muy presente que las características deestos flujos pueden variar drásticamente con el diseño de la red. Por ejemplo, los nodosde almacenamiento local de páginas web (cache engines) modifican por completo lascaracterísicas de los flujos entre el cliente y el servidor (original).

Caso de estudio.- Documentación del flujo

Diseño y Arquitectura de Redes Telemáticas 75

Page 86: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

La documentación necesaria para caracterizar los flujos se empieza a integrar identi-ficando las áreas de la organización, el número de empleados por área, las aplicaciones(fuentes de información) comúnmente utilizadas en esa área, su ubicación física (gene-ralmente ésta se encuentra relacionada de alguna manera con la topología de la red) yotra información que pueda parecer relevante. Esta información puede conjuntarse en unatabla como la siguiente.

Área Usuarios Aplicaciones S. Op. Ubicación

Contabilidad 56 Office, Exchange, SAP W98 Corp. Edif. 2Ingeniería 200 Web, Exchange, Office, CAD, Visio W2K, Solaris Corp. Edif 2, MéridaFinanzas 25 Web, Office, Exchange, Bloomberg, Infosel W2K Corp. Edif. 2

Pers. admin 33 Web, Office, Exchange W98 Toda la empresaEjecutivos 20 Web, Office, Exchange, Blomber, Infosel,

SAPW2K Corp. Edif. Princ.

Operaciones 22 Office, Exchange W98 MéridaSistemas 15 Web, Office, Exchange, SQL, SAP, Visio,

Adm. RedW2K Corp. Edif. 1

Al mismo tiempo, deberán identificarse las principales aplicaciones generadoras deinformación, los repositorios de información y las características principales de los flujosgenerados. Esta información también se presenta en una tabla como la siguiente.

Repositorio Area Características S. Op. UbicaciónBD SAP Finanzas RPC Asim BD a

Servs. AplicaciónHP9000 Corp. Edif. 1

Aplicaciones SAP Finanzas y Ejecutivos RPC Asim. Serv.Aplic a usuarios

W2K Corp. Edif. 2

Bloomberg Infosel Piso financiero y Ejecutivos C/S, T. Real Internet Internet/Edif. 1Serv. Exchange 1 Corporativo Edif. Princ. RPC Asim W2K Corp. Edif. 1Serv. Exchange 2 Ingeniería RPC Asim W2K MéridaServ. Exchange 3 Secretarias y Operaciones RPC Asim W2K Mérida

Serv. Red 1 Corporativo Edif.. Princ. C/S y Peer W2K Corp. Edif. 1Serv. Red 2 Mérida C/S y Peer W2K Mérida

Serv. Archivos Cada piso Corp. C/S W2K Todos

A partir de las tablas anteriores se puede generar una especie de matriz de tráfico quevincula los repositorios y generadores de información con sus usuarios como se muestraen la tabla siguiente. Esa matriz se podrá asociar a la topología física de la red paraidentificar si los enlaces y equipos involucrados están dimensionados adecuadamente.

Diseño y Arquitectura de Redes Telemáticas 76

Page 87: Diseño y Arquitectura de Redes Telemáticas

3.3. CARACTERIZACIÓN DEL FLUJO

Corp Edif. 1 Corp Edif. 3 Corp Edif. 2 Corp Ed. Princ Mérida

Fuentes Proto Mbps Ruta Mbps Ruta Mbps Ruta Mbps Ruta Mbps Ruta

BD SAP RPC/TCP/IP 2 Local 0 R1-R10 0.5 R1-R12 0 R1-R39 0.1 R1-Inet

Aplicaciones SAP RPC/TCP/IP 2.4 Local 0.2 R1-R10 1 R1-R12 0.3 R1-R39 0.7 R1-Inet

Bloomberg Infosel TCP/IP 1 Inet 1 R1-R10 0 R1-R12 1 R1-R39 0 Internet

Serv. Exchange 1 RPC/TCP/IP 3 Local 0.4 R1-R10 0.05 R1-R12 0.6 R1-R39 1.15 R1-Inet

Serv. Exchange 2 RPC/TCP/IP 0.5 Inet PPTP 0 R1-R10 0 R1-R12 0 R1-R39 1.2 Local

Serv. Exchange 3 RPC/TCP/IP 0.2 Inet PPTP 0 R1-R10 0 R1-R12 0 R1-R39 0.9 Local

Serv. Red 1 WINS/DHCP/IP 0.3 Local 0.1 R1-R10 0.05 R1-R12 0.1 R1-R39 0.2 R1-Inet

Serv. Red 2 WINS/DHCP/IP 0.1 Inet PPTP 0 R1-R10 0 R1-R12 0 R1-R39 0.3 R1-Inet

Serv. Archivos SMB/NBT/IP 1 Local 1 Local 0.5 Local 0.3 Local 0.2 Local

3.3.2. Caracterización del volumen de tráfico

La caracterización de la carga es obviamente necesaria para poder cumplir con losobjetivos de diseño: en general, la capacidad de la red debe poder satisfacer la cargaestimada. La manera más fácil de medir un flujo es utilizando un analizador de protocoloso un monitor de red como se ha mencionado en el capítulo 2. Sin embargo, este modelosolamente puede aplicarse –y parcialmente– a los flujos ya existentes. La estimación dela carga para los nuevos flujos es bastante imprecisa.

Existen demasiados factores que influyen en las características del tráfico de red. Elobjetivo no es hacer una estimación muy precisa, sino evitar cuellos de botella críticos.

Para evitar cuellos de botella críticos, deben analizarse los patrones de uso de lasaplicaciones, los intervalos entre paquetes y las sesiones, los tamaños de paquete y lospatrones característicos introducidos por los protocolos de red.

Estimación de la carga

Es necesario conocer el tamaño de los objetos que se transmiten en cada aplicacióny la sobrecarga introducida por los protocolos que utilizan. De ser posible, se deberánobtener métricas que caracterizan a cada fuente tratando de evaluar el comportamientoy las demandas de servicio de las aplicaciones existentes. Para aplicaciones "típicas"sepodrá recurrir, con ciertas reservas, a tablas de referencia como las que se mostrarán másadelante.

Para cada flujo identificado, debe investigarse el número de usuarios simultáneos, eltamaño de sus ráfagas y la frecuencia de transmisión para calcular la capacidad agregadanecesaria por aplicación.

Mientras la sesión está activa, con ayuda de un analizador de protocolos es posiblemedir el intervalo medio entre paquetes (MTBA) y por consiguiente el número medio depaquetes por segundo. También es posible estimar el tamaño medio de los paquetes para

Diseño y Arquitectura de Redes Telemáticas 77

Page 88: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

así estimar el ancho de banda promedio por sesión y, de esta forma, el ancho de bandarequerido para esa aplicación.

Con esta información, y dado que ya se conocen las tablas de las comunidades deusuarios y sus rutas, se podrá tener una estimación de la carga por segmento. Con ellose podrá elegir la tecnología más apropiada para el núcleo y para los dispositivos deconmutación.

La ecuación siguiente utiliza los parámetros anteriores y algunos elementos de retardopara dar una aproximación del ancho de banda necesario para una aplicación:

Bw =8× (NA ×K × L)

K × P + T,

donde Bw es el ancho de banda estimado, NA el número medio de sesiones, K elpromedio de paquetes por sesión y L el tamaño medio de paquete. P es la latencia de lared en uno solo sentido y T es el "think time", es decir, el tiempo estimado que duraría unusuario de la aplicación en procesar o explotar la información recibida antes de solicitarun nuevo mensaje.

Por supuesto, aquí se está hablando de valores promedio, lo que permite simplificarenormemente el dimensionamiento pero que no necesariamente corresponderán con losvalores observados. Una mejor aproximación es la de representar los flujos por medio dedistribuciones aleatorias y utilizar la teoría de colas para estimar el comportamiento deéstos. En el capítulo 7 se presentarán las ventajas y limitaciones de esta técnica.

Los patrones de uso están relacionados con el nivel de sesión: ¿Cuánto dura en pro-medio una sesión? ¿Cuál es el intervalo entre sesiones por usuario? ¿Cuántos usuarios oestaciones hay? Con esto, y un análisis estadístico, se puede establecer cuántas sesionesen promedio se están ejecutando simultáneamente.

Si no se cuenta con la información necesaria, a veces será necesario considerar el peorcaso: todas las aplicaciones están siendo utilizadas al mismo tiempo y hay tantos usuariosde cada aplicación como usuarios hay en la comunidad de estudio.

Estimación de volumen por aplicación

Es claro que las aplicaciones y los patrones de uso varían demasiado. Sin embargo,es necesario contar con una referencia para poder estimar la carga generada por éstas.La siguiente tabla, hecha alrededor de 1999, da una idea vaga del volumen generado poralgunas aplicaciones para hacer estimaciones rápidas.

Diseño y Arquitectura de Redes Telemáticas 78

Page 89: Diseño y Arquitectura de Redes Telemáticas

3.3. CARACTERIZACIÓN DEL FLUJO

Aplicación Volumen (kBytes)

Pantalla de terminal 4Mensaje de correo electrónico 10Página Web 50Hoja de Excel 200Documento de Word 200Presentación de PowerPoint 1, 000Video MPEG-4 (30 seg) 4, 000Imagen de alta resolución 50, 000Respaldo de una base de datos 1, 000, 000

Estimación del volumen por sobrecarga de protocolos

Para calcular el volumen total de tráfico transportado por la red, no basta con calcularel tráfico generado por las aplicaciones. También debe considerarse la sobrecarga de losprotocolos de transporte y el volumen generado por otros protocolos y aplicaciones quesirven de soporte a la operación de la red. En lo que respecta a los protocolos de transporte,la tabla siguiente muestra la sobrecarga de algunos de los protocolos más comunes.

Protocolo Sobrecarga (Bytes)

Ethernet 18 + 20IEEE802.3, IEEE802.2 y SNAP 26 + 20HDLC 10IPv4 20IPv6 40TCP 20IPX 30

En el caso de ethernet y de IEEE 802.2, los 20 bytes extra corresponden a 8 de preám-bulo (que en realidad es variable) y los 12 de separación entre tramas. Este último, porsupuesto, no es tráfico que se genera pero afecta la eficiencia del medio.

La actualización de rutas, en particular con protocolos de vector de distancia, puedetener un impacto importante en redes grandes en capacidad de procesamiento de los enru-tadores. Su impacto en la capacidad de los enlaces típicamente es muy poca y sólo tieneun impacto importante cuando los enlaces están muy limitados en ancho de banda.

Caso de estudio.- Un ejemplo bien conocido sobre el impacto que los pro-tocolos de enrutamiento pueden tener sobre la red data de principios de losaños 90 en que se realizaban los primeros experimentos de transferencia deaudio y video sobre internet entre Europa y los Estados Unidos.

La calidad de las comunicaciones era muy inferior a lo esperado. Al revisarlas trazas de tráfico, se encontró que la latencia de los paquetes sufría degra-daciones muy importantes cada dos minutos aproximadamente. Tras muchos

Diseño y Arquitectura de Redes Telemáticas 79

Page 90: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

estudios, se concluyó que este comportamiento estaba relacionado con el in-tercambio y la actualización de tablas de ruteo al interior de algunos de losenrutadores en el enlace intercontinental.

Varios protocolos comunes en redes locales utilizan tramas de difusión para su ope-ración. Estas tramas también deben ser tomadas en cuenta. Además, un número excesivode tramas de difusión puede degradar seriamente la eficiencia de la red.

Dinámica de los protocolos de transporte Además de la sobrecarga de los encabeza-dos, los protocolos de transporte controlan cómo y cuándo se envía la información, lo cualincide directamente en las características del trafico y en la carga observada. Por ejemplo,si la capa de enlace y la de transporte ofrecen ambas un servicio confiable y los tempori-zadores de la primera no están bien configurados, habrá retransmisiones innecesarias.

En protocolos de ventana deslizante, como TCP, el tamaño de la ventana está asociadoa la cantidad de información que puede viajar en la red ("llenar el tubo"), la cual es igual alproducto ancho de banda por el retraso de ida y vuelta (RTT). Si la ventana es menor a estetamaño (como ocurre en redes satelitales o de fibra óptica de gran distancia), la ventanalimitará la eficiencia de la conexión. Dicho esto, una ventana grande puede introduciruna ráfaga grande de información a la red, lo que puede acarrear otras consecuencias nodeseables, como congestión temporal en los nodos de conmutación y jitter.

Para proteger la red ante un exceso de carga, muchos protocolos de transporte utilizanmecanismos de control de congestión que también influyen en las características de losflujos, por lo que se recomienda conocer qué mecanismos de control de congestión seestán utilizando: de lazo abierto (token bucket), reactivos por los nodos (ECN, ABR) o delazo cerrado en los extremos (TCP). Si no hay una forma de reacción a la congestión, lared puede quedar completamente inhabilitada.

Influencia de otros componentes Debe tomarse en cuenta el tráfico generado por otrosprotocolos en los que se basa la operación de la red y que no se utilizan directamente parael transporte de los flujos de las aplicaciones como:

La configuración automática con DHCP (que se presenta en el capítulo 4) generaintercmbios de 328 bytes;

se considera que un mensaje del protocolo de administración SNMP (capítulo 6)utiliza 128 bytes por variable monitoreada.

Dependiendo de las condiciones de la organización y de la configuración de su red,es posible que se detecten ráfagas de mensajes DHCP en ciertos momentos del día. Aun-que es poco común, estas ráfagas pueden afectar el desempeño de la red por saturaciónmomentánea de los enlaces, o por falta de capacidad de procesamiento en los servidores.

Como se verá más adelante, la granularidad con que deben ser monitoreadas las va-riables de administración no debe ser muy fina para reducir el tráfico en la red.

Diseño y Arquitectura de Redes Telemáticas 80

Page 91: Diseño y Arquitectura de Redes Telemáticas

3.3. CARACTERIZACIÓN DEL FLUJO

Figura 3.8: Flujos de tráfico en aplicaciones unicast y multicast.

Copias de tráfico Para ciertas aplicaciones, como la difusión de video en demanda,vuelve a tomar importancia el uso de sistemas que faciliten la difusión restringida (multi-cast) de la información. En el capítulo 9 se mostrará cómo estos sistemas permiten hacerun uso más eficiente de los recursos de la red al evitar copias innecesarias, como se indicaen la figura 3.8. Observe que en el caso de transmisiones unicast, en el enlace de la iz-quierda se genera un flujo por cada receptor de la información, mientras que en un sistemaque soporte multicasting, son los enrutadores los que generan réplicas de la informaciónen caso de ser necesario.

Por supuesto, al establecer la caracterización de los flujos, deberá conocerse si seemplean protocolos de difusión restringida en la organización.

Otro elemento que debe tomarse en cuenta, es que si bien se ha tratado de caracterizarlos flujos de las fuentes de manera individual, su combinación para estimar el volumentotal no es tan sencillo como la suma aritmética que se pretende simbolizar en la figura 3.9.

Figura 3.9: La mezcla de fuentes no puede realizarse como una superposición de flujos

En realidad éste es un problema bastante complejo. El reto es cómo lograr un modeloque permita mezclar las fuentes para determinar la capacidad que será requerida y asípoder estimar los retardos que sufrirán las distintas fuentes.

Para redes donde las métricas de desempeño son críticas, el dimensionamiento puederealizarse considerando el peor caso en el que los picos de cada flujo coinciden en eltiempo. Sin embargo, esto genera redes sumamente sub-dimensionadas y costosas. En lamayoría de los casos se utiliza un multiplexaje estadístico basado en alguna técnica demodelado.

Diseño y Arquitectura de Redes Telemáticas 81

Page 92: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

3.3.3. Requerimientos de calidad de servicio

La calidad de servicio (QoS, Quality of Service) parte del hecho de que no todaslas aplicaciones tienen las mismas necesidades y, por lo tanto, no demandan los mismosrecursos de la red. Por ello, no basta con caracterizar el tráfico y la carga. También hay queidentificar los requerimientos de los distintos flujos que se han identificado. La siguientetabla muestra algunos requerimientos de QoS para algunas aplicaciones típicas.

Rango Burst- Longitud Tolerancia ToleranciaTipo Categoría Capacidad CBR/VBR iness ráfaga pérdidas retardoVoz PCM 64 kbps CBR 1 N/A 10−4 − 10−6 10 - 150 msVoz ADPCM 32 kbps CBR 1 N/A 10−4 − 10−7 10 - 150 msVoz Alta Calidad 192-384 kbps CBR 1 N/A 10−4 − 10−7 10 - 150 msVoz Voice mail 16-64 kbps CBR/VBR 1-3 2-3 kB 10−6 0.5 a 5 sVoz Calidad CD 1.4 Mbps CBR 1 N/A 10−6 0.5 a 25 sVoz Audioconf. 64-192 kbps CBR 1 N/A 10−7 − 10−9 10-150 ms

Datos Transf. Arch.64 k -1.5 Mbps VBR 1 12 kB-10 MB 10−12 1-150 sDatos Aplic. C/S 10-100 Mbps VBR 1000 1-500 kB 10−9 10-500 msDatos eMail 9.6 k-1.5 Mbps VBR 1 50-5000 B 10−9 1-10 sDatos Sist. Transac. 64 k-5 Mbps VBR 40 100-300 B 10−9 1-3 sVideo Videoconf. 128 k-14 MbpsCBR/VBR 2-5 1.6- 40 kB 10−9 150-300 msVideo TV NTSC 15- 44 Mbps VBR 2-5 0.5-1.3 MB 10−10 40 msVideo TV HDTV 150 Mbps VBR 2-5 5-14 MB 10−12 40 msVideo FAX Gpo. 4 64 kbps CBR 1 256-640 kB 10−8 4-10 s

Los distintos tipos de flujo son más o menos tolerantes al retardo que pueden sufriren la red. Una transferencia de archivos es relativamente inmune al retardo y a su varia-bilidad. A este tipo de flujos suele llamársele elásticos. En cambio, un flujo de audio paraaplicaciones interactivas es sumamente estricto en sus requerimientos de retardo y jitter.Estas aplicaciones se llaman inelásticas.

Existen diversos mecanismos para garantizar la calidad de servicio en la red. Dichosmecanismos son discutidos en forma general en el capítulo 8, pero el concepto central sebasa en hacer posible que cada aplicación pueda solicitar de la red una garantía de que losrecursos que necesita estarán disponibles.

Es importante señalar el hecho de que aún cuando los mecanismos mencionados per-miten a las aplicaciones solicitar los recursos necesitados, siempre quedará en manos deladministrador de la red el decidir si dichos recursos son autorizados o no.

Cada aplicación puede indicar sus requerimientos específicos hacia la red antes deiniciar la transmisión de datos. El çontrato"hacia la red (SLA, Service Level Agreement)se negocia especificando típicamente el tipo de tráfico, su variabilidad en la intensidad(burstiness), el ancho de banda, latencia y jitter requeridos y la tasa de pérdida tolerada.

La terminología de ATM es útil para poder clasificar las aplicaciones y para poderdeterminar los parámetros que determinan la calidad de servicio requerida. En ATM haycinco categorías de servicio: CBR (Constant Bit Rate), rt-VBR (Real-time Variable BitRate), nrt-VBR (non real-time Variable Bit Rate), ABR (Available Bit Rate) y UBR (Uns-

Diseño y Arquitectura de Redes Telemáticas 82

Page 93: Diseño y Arquitectura de Redes Telemáticas

3.3. CARACTERIZACIÓN DEL FLUJO

pecified Bit Rate).

Para cada una de ellas, el forum ATM indica una serie de parámetros que describenel tráfico y los requerimientos de QoS de la red. Ejemplos de estos parámetros son PCR(peak cell rate), SCR (sustainable cell rate), max CTD (cell transfer delay), y MBS (maxburst size).

Tráfico CBR Esta categoría está pensada para aplicaciones que generan una tráfico conuna tasa constante como es el caso de una conversación telefónica y la transmisión devideo sin compresión. Este tipo de flujos demanda de la red una capacidad constante enbits por segundo (ver figura 3.10 (a)), un retardo máximo predecible, una variabilidad delretardo y tasa de pérdidas mínimas.

Es común que si la red puede ofrecer garantías para el tráfico CBR, este servicio seutilice para otros objetivos, como la interconexión de redes locales.

CBR

PBR

MBR

(a) Tráfico CBR (b) Tráfico VBR

Figura 3.10: Ejemplo de flujos a tasa constante y a tasa variable

Tráfico VBR. El tráfico VBR es el tipo de tráfico típico en las aplicaciones de red"tradicionales"las cuales generan flujos de información en ráfagas seguidas de períodosde silencio, lo que produce una tasa variable de información (figura 3.10 (b)). Algunasaplicaciones de tiempo real, como el video comprimido, también generan un tráfico VBR(por ello la categoría rt-VBR) y demandarán de la red un retardo máximo predecible,aunque normalmente menos rígido que para los flujos CBR.

Existen varias definiciones distintas para medir la variabilidad en la intensidad con laque las aplicaciones ïnyectan"tráfico a la red. Este término es lo que en inglés se llamaburstiness. Una medida muy popular de burstiness es la relación entre la tasa de emisiónpico (PBR, Peak bit rate) y la tasa promedio (MBR, Mean bit rate).

Burstiness =PBR

MBR

Una aplicación CBR tiene un burstiness muy bajo; una VBR puede tenerlo muy alto.Otras formas de evaluarla son a través de la duración de la ráfaga o de su probabilidad deocurrencia.

Diseño y Arquitectura de Redes Telemáticas 83

Page 94: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

Distribución del ancho de banda

Para poder satisfacer los requerimientos de calidad de servicio, la infraestructura dela red debe contar con mecanismos que permitan distribuir la capacidad disponible enlos enlaces de acuerdo al nivel de importancia de los distintos flujos (o de las clases deservicio, como se verá en el capítulo 8.

En los mecanismos llamados de conservación de trabajo, cuando la carga es ligera lacapacidad se distribuye entre los distintos flujos, pero conforme la demanda empieza aaumentar rebasando la capacidad de la red, los anchos de banda se asignan en función deprioridad, como aparece en la figura 3.11

Figura 3.11: Distribución del ancho de banda en función de la prioridad de los flujos

Algunas aplicaciones, como las que generan tráfico CBR, o algunas aplicaciones demisión crítica, requieren de la asignación de un ancho de banda determinado. Si el ad-ministrador está de acuerdo, entonces el ancho de banda de la línea de comunicacionesse divide entre los diferentes tipos de aplicación, y se pueden realizar múltiples sesionessobre un mismo espacio asignado.

3.4. Problemas

3.1. ¿Cómo se realiza y para qué sirve el baselining de la red en Diseño de Redes?

3.2. Llene la siguiente tabla

Diseño y Arquitectura de Redes Telemáticas 84

Page 95: Diseño y Arquitectura de Redes Telemáticas

3.4. PROBLEMAS

Aplicación Direccionalidad Simetría Burstiness

Telnet

HTTP

Respaldo servidores

Video en demanda

Audio conferencia

3.3. Caracterice los siguientes flujos en función de su: a) Direccionalidad:uni/bidireccional;b) Simetría: (en relación con los volúmenes de información en cada dirección; c)Tolerancia al retardo: elástica/inelástica; d) Disponibilidad: misión crítica, o no.Justfique brevemente su respuesta

Telemetría

Video conferencia para empresas

Visualizador realidad virtual para síntesis de proteinas

Sistema para autorización de tarjetas de crédito en tienda departamental

3.4. ¿Cuáles son los valores que los siguientes parámetros deben tener para consi-derar que la red es "sana¿

Porcentaje de utilización de un segmento ethernet

Disponibilidad de las aplicaciones de misión crítica

Porcentaje de colisiones

Porcentaje de paquetes perdidos

Porcentaje de utilización de CPU en enrutadores.

3.5. ¿Cuáles son los valores típicos de BER en enlaces:(a) de cobre(b) de fibra óptica(c) satelitales?

3.6. Si un proyecto de diseño de redes debe incorporarse a una infraestructura de redya existente, ¿cómo es posible asegurar que el diseño propuesto será interoperabley que los objetivos de diseño son realistas?

3.7. Describa brevemente y proporcione un ejemplo de mecanismos de control decongestión de:

Diseño y Arquitectura de Redes Telemáticas 85

Page 96: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 3. CARACTERIZACIÓN DE LA RED

Lazo abierto

Reactivos en los nodos de conmutación

Lazo cerrado en los extremos.

3.8. Se envía información con un protocolo de ventanas deslizantes por un enlace de155Mb/s. La distancia entre transmisor y receptor es de 800 km. La velocidad depropagación en el medio es de 200, 000 km/s. ¿Cuál debe ser el tamaño máximo dela ventana para que no se degrade la eficiencia de la comunicación por esta razón?

3.9. ¿Por qué el mecanismo de control de congestión de TCP puede ser ineficienteen redes limitadas en latencia y qué modificaciones se han propuesto para mejorar-lo?

3.10. ¿Qué elementos se deben tomar en cuenta para estimar el volumen de losflujos que fluyen por la red?

3.11. Si durante la caracterización de la red se utiliza un analizador de protocolospara monitorear el tráfico, ¿durante cuánto tiempo y con qué frecuencia se debecapturar la información que nos interesa?

3.12. ¿Qué relación hay entre un histograma y una pdf de una métrica de desempe-ño? ¿Qué propiedades estadísticas tiene la pdf?

3.13. ¿Cómo es la varianza de una distribución Pareto con parámetro de formaβ < 1?

3.14. ¿Para qué tipo de variable recomendaría utilizar como medida de dispersiónla desviación estándar? ¿Los percentiles 5 % y 95 %?

3.15. ¿Qué significa "Burstiness 2cómo se calcula? ¿Qué significa el término Jittery cómo se relaciona con la QoS?

3.16. ¿Qué es un proceso de Poisson? ¿Por qué suele utilizarse para modelar tráficoen redes de datos? ¿En qué casos este modelo puede no ser adecuado?

3.17. ¿Por qué es cuestionable modelar el tráfico de aplicaciones çlásicasçon pro-cesos de Poisson? ¿Podría modelarse el flujo de VoIP como Poisson?

3.18. Describa brevemente cuáles son las características de los flujos definidos porel foro de ATM y de un ejemplo de una aplicación que genere cada tipo de flujo.

Diseño y Arquitectura de Redes Telemáticas 86

Page 97: Diseño y Arquitectura de Redes Telemáticas

Capítulo 4

Diseño lógico de la red

El diseño lógico de la red consiste no solamente en definir la topología de intercone-xión entre los distintos componentes que la conforman. En esta etapa también se deter-minan las tecnologías para llevar a cabo dicha interconexión. También se establecen laspolíticas de asignación de direcciones y de nombres, las de seguridad y las de adminis-tración de la red. Todos estos elementos serán críticos para que la red cumpla de maneraeficiente con los objetivos de diseño establecidos.

El diseño de la red se asemeja más a un arte que a una ciencia: No hay absolutos,no hay fórmulas exactas que puedan utilizarse ciegamente en todos los casos. Sin em-bargo, hay un conjunto de mejores prácticas a partir de las cuales se podrán tomardecisiones más informadas durante el proceso de diseño.

4.1. Diseño de la topología

En la metodología descendente, el primer paso del diseño lógico es el diseño de latopología de la red. La topología es un mapa en el que se identifican segmentos, puntosde interconexión y comunidades de usuarios. Con esta información se puede tener unaprimera apreciación de las capacidades de los dispositivos y enlaces pero no se puedenelegir aún los dispositivos específicos con los que se construira la red.

En redes de comunicaciones, básicamente es posible identificar tres tipos de topología:

Plana.- Topología convencional en la que todos los dispositivos de conmutación tienenla misma funcionalidad.

Amorfa.- También conocida como de spaghetti, es una anarquía; la interconexión en-tre nodos se hace sin orden ni planeación. Es el efecto directo de un crecimientoreactivo y no planeado. Tarde o temprano ocasiona serios problemas para la ges-tión de la red, el dimensionamiento de enlaces, la implementación de políticas deenrutamiento, etc.

Page 98: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

Jerárquica.- Agrupamiento ordenado de nodos y enlaces. El tráfico con destinos comu-nes se va agrupando y fluye por enlaces principales para llegar lo más cerca de sudestino y ahí proceder a la desagregación.

4.1.1. Topología plana

Algunos ejemplos de topologías planas bien conocidas se muestran en la figura 4.1.

Figura 4.1: Ejemplos clásicos de topologías planas de redes

Las topologías planas son sencillas de diseñar e implementar. Tambíen son fácilesde administrar en redes pequeñas, por lo que se encuentran comúnmente en redes conpocos dispositivos. Una de las principales limitantes de estas topologías es su falta deescalabilidad. En la topología de anillo, está limitada por el número de saltos que habríaque dar para llegar de un extremo a otro, lo que provoca una latencia variable entre dosnodos cualesquiera que deseen comunicarse, y muy grande para la comunicación entrelos extremos.

En la estrella, también llamada hub and spoke, la escalabilidad queda limitada por elnúmero de puertos en el nodo central. Además, hay un punto único de falla y un potencialcuello de botella de procesamiento. Por otro lado, al tener un punto central donde fluye lainformación, esta topología es muy útil para gestionar la red y controlar la seguridad.

Las topologías de malla parcial o total son sumamente costosas. En la malla total, enparticular, es muy difícil agregar un nuevo nodo. Además, el desempeño estará en funcióndel número de vecinos que tiene un nodo enrutador: se debe recordar que la actualizaciónde las tablas de ruteo requiere de la atención de mensajes de difusión, lo cual consumerecursos de CPU en la mayoría de los enrutadores. Entre más vecinos enrutadores haya,peor será el desempeño.

Por otra parte, es muy complicado establecer el enrutamiento en este tipo de configu-ración. También se dificulta el mantenimiento y actualización por la falta de modularidad.Como se ha mencionado, algunos de estos problemas también se detectan en las topolo-gías de spaghetti.

4.1.2. Diseño jerárquico

El diseño jerárquico proporciona un enfoque estructurado que busca obtener una redmás fácil de entender, administrar, planear y escalar. Consiste en dividir la red encapas, cada una responsable de realizar una función específica.

Diseño y Arquitectura de Redes Telemáticas 88

Page 99: Diseño y Arquitectura de Redes Telemáticas

4.1. DISEÑO DE LA TOPOLOGÍA

En los primeros diseños jerárquicos se definían dos capas: la red de acceso, encar-gada de ofrecer conectividad a los usuarios finales, y el núcleo, cuyo objetivo central esproporcionar interconexión eficiente entre los distintos sitios.

Conforme han evolucionado las redes, se ha propuesto incluir una tercera capa: la dedistribución, encargada de ofrecer los servicios del núcleo a la capa de acceso definiendolas políticas necesarias. Por ejemplo, en esta capa se puede llevar a cabo la agregación derutas, la traducción de direcciones y la implementación y monitoreo de las políticas deseguridad establecidas.

La figura 4.2 representa esquemáticamente las tres capas de un diseño jerárquico. Enel modelo de la derecha se incluyen enlaces redundantes entre la capa de acceso y la dedistribución. Estos enlaces mejoran el desempeño y aumentan la disponibilidad de la red,como se verá en la sección 4.6.

Figura 4.2: Diseño jerárquico de tres capas

Dependiendo de las características de la red, los nodos en cada capa pueden ser enru-tadores, conmutadores, concentradores o puede haber una combinación de dispositivos,como se muestra en la figura 4.2. Por ejemplo, en una LAN, la capa de acceso podría estarformada por concentradores y conmutadores para conectar usuarios finales. En cambio,en una red WAN la capa de acceso podría consistir en los enrutadores de salida de lasredes locales.

El diseño jerárquico en capas ha adquirido una creciente atención debido a las múlti-ples ventajas que ofrece, entre las que cabe destacar las siguientes:

Permite reducir costos al utilizar equipo especializado en cada nivel. Por ejemplo,los dispositivos en la capa de acceso pueden necesitar una gran densidad de puertosde bajo costo, mientras que los dispositivos en el núcleo tendrán pocos puertos dealta velocidad y su prioridad será una muy alta tasa de conmutación;

Diseño y Arquitectura de Redes Telemáticas 89

Page 100: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

al elegir los dispositivos apropiados en cada capa, permite aislar los dominios dedifusión, mejorando así el desempeño de los enrutadores y estaciones de trabajo;

permite una mejor planeación de capacidad, y en consecuencia, un mayor escala-miento;

permite una administración sencilla pues se cuenta con una red con una estructuralógica coherente. También simplifica la evolución gradual de la red;

simplifica el aislamiento de fallas, lo que facilita un diseño que contemple la conti-nuidad del negocio;

simplifica la planeación de agregación de rutas, lo que se traduce en un menoruso de ancho de banda para anunciar rutas y un menor consumo de CPU en losenrutadores.

La mayoría de los protocolos de enrutamiento de convergencia rápida en uso actual-mente, como OSPF (Open Shortest Path First), IS-IS (Intermediate System to Interme-diate System), BGP (Border Gateway Protocol) y EIGRP (Enhanced Interior GatewayProtocol) fueron diseñados para emplearse en redes jerárquicas.

Al optar por un diseño jerárquico, hay ciertas recomendaciones que deben seguirsecon el fin de explotar al máximo las ventajas de esta metodología, entre las que destacan:

1. Se debe limitar el número de capas (llamado diámetro) para mantener la latenciabaja y predecible. Esto también permite estimar las trayectorias de enrutamiento ylos flujos de tráfico, para planificar adecuadamente la capacidad de los enlaces.

2. El diseño de la red comienza con la capa de acceso y de ahí se mueve hacia aden-tro. Empezar en la capa de acceso permite una mejor planeación de la capacidadque se requerirá en las capas superiores. También se empieza a pensar en las posi-bles tecnologías y optimizaciones que se podrían aplicar a esos niveles tomando enconsideración que en cada nivel se debe mantener el diseño lo más modular posible.

3. Se debe mantener un estricto control de la capa de acceso, que es la más vulnerable.A través de un reforzamiento de las políticas de la empresa, se debe evitar quelos administradores locales establezcan enlaces directos entre oficinas regionales(llamados cadenas), lo cual en términos prácticos representa la creación de unacuarta capa. También se deben evitar "puertas traseras", es decir, enrutadores queconectan entre sí dos redes en una misma oficina regional. Esto introducirá una seriede problemas de ruteo muy difíciles de identificar y corregir. Además, la seguridadde la red está en juego pues las políticas de seguridad están implementadas en lacapa de distribución.

A veces las cadenas son necesarias, por ejemplo para agregar una nueva ciudad quesolo tiene conectividad con otra. Por su parte, se tiende a meter una puerta traserapara aumentar el desempeño o por redundancia. En ambos casos, se puede encontrargeneralmente una configuración que no viole el diseño jerárquico.

Diseño y Arquitectura de Redes Telemáticas 90

Page 101: Diseño y Arquitectura de Redes Telemáticas

4.2. DISEÑO DE LA CAPA DE ACCESO

4.2. Diseño de la capa de acceso

La función principal de esta capa es proporcionar acceso a la red de la empresa agrupos de usuarios locales. Una LAN generalmente está conformada por concentradoresy conmutadores, pero puede incluir los enrutadores que están en el límite exterior de uncampus. En el caso de redes WAN la capa de acceso determina la conectividad de losnodos y usuarios en una misma región geográfica, por ejemplo, una ciudad.

En grandes redes, esta capa debe dar acceso a cientos o miles de usuarios, por lo queresulta prioritario encontrar una solución a costo mínimo.

El objetivo central de diseño en la capa de acceso es maximizar el desempeño a uncosto mínimo cumpliendo los requerimientos fijados.

Para reducir los costos, en la capa de acceso se busca típicamente agrupar el tráficode varios usuarios (también llamados terminales) en nodos concentradores y estableceruna topología de interconexión. Así, el problema de diseño en la capa de acceso puededividirse en tres sub-problemas:

1. Seleccionar los mejores candidatos para concentrar en ellos el tráfico de los usua-rios.

2. Seleccionar qué usuarios se conectan a qué concentradores.

3. Definir la topología de interconexión en cada caso.

Estos problemas pertenecen a una categoría que se conoce genéricamente como Fa-cility loaction problem. Se ha demostrado que en el caso general estos problemas sonNP-Completos1, por lo que se han propuesto diversas heurísticas para resolverlos. En lassecciones siguientes se presentan algunas de ellas.

Aunque las heurísticas mostradas tienen muchos años de ser conocidas (por ejemplo,el método de Kruskal data de 1956), variantes de estas técnicas tienen muchas aplica-ciones en las redes actuales. Por ejemplo, para establecer una primera aproximación ala ubicación de radiobases y puntos de acceso en redes inalámbricas; para ubicar mul-tiplexores en anillos ópticos; para seleccionar puntos de presencia (PoP) de operadores;etc.

4.2.1. Problema de Localización-asignación

El diseño de la red de acceso inicia estableciendo cuántos concentradores se necesitanpara una determinada población de usuarios (o terminales) y dónde conviene colocarlos.

1Para un problema NP-Completo no se tienen algoritmos que proporcionen soluciones en tiempo poli-nómico, es decir, el tiempo esperado para resolverlo es el que tardaría una búsqueda exhaustiva de todas lasposibilidades.

Diseño y Arquitectura de Redes Telemáticas 91

Page 102: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

Las localidades donde conviene concentrar el tráfico de los usuarios suelen ser unsubconjunto de los sitios donde éstos se encuentran. La selección específica de locali-dades dependerá del número de puertos disponibles, de la capacidad de los enlaces ydel tráfico esperado. Sin embargo, resulta apropiado partir de una primera selección decandidatos, por lo que se presenta en primer término un algoritmo sin restricciones, esdecir, se asociará un costo a los enlaces (que puede ser distancia, número de saltos, retraso,etc.) pero no se tomarán en cuenta limitaciones en ancho de banda de los enlaces nicapacidades de los equipos.

Algoritmo de Dysart-Georganas

El algoritmo de Dysart-Georganas permite identificar los mejores candidatos para sernodos concentradores utilizando como criterio el grado de vecindad, o número de nodosvecinos cercanos. Utiliza un parámetro K que representa el número de nodos vecinos queun concentrador puede interconectar. Sea N el número de nodos en la red. El algoritmoes el siguiente:

1. Se genera una lista de nodos con sus K vecinos más cercanos.

2. Se obtiene una tabla con la frecuencia j con que aparece cada nodo en la lista devecinos.

3. Se calcula el número promedio de vecinos a partir de la tabla de frecuencias:

v̄ =⌊ F

Σj=1Sj × j

N

⌋+ 1

4. Los candidatos idóneos son aquellos nodos con un número de vecinos superior alpromedio v̄.

EJEMPLO 4.1. Considere la red de la figura ??. Las líneas entre los nodosrepresentan enlaces potenciales con el costo indicado en cada una. Se buscaelegir a los mejores candidatos para un valor de K = 3.

Se construye una tabla de vecindades con los K = 3 vecinos más cercanos(es decir, con la métrica menor), para cada nodo. Por ejemplo, para el nodo5 se eligen los tres vecinos con un costo de una unidad. En la tabla de ve-cindades del ejemplo, la segunda columna muestra los vecinos más cercanos.La columna de frecuencia representa el número de ocurrencias de cada nodo(incluyéndose a sí mismo) en la lista de vecindades. Por ejemplo, el nodo 5aparece como vecino cercano de 5 nodos (los nodos 1, 2, 3, 4 y 6) más élmismo, lo que da una frecuencia de 6.

Diseño y Arquitectura de Redes Telemáticas 92

Page 103: Diseño y Arquitectura de Redes Telemáticas

4.2. DISEÑO DE LA CAPA DE ACCESO

1

2

3

4

5

6 7

89

10

�����

3

!!!!!!!!34

bbbb1

""""2

22

aaaaa2

,,,,

1bbbb1 �

���2

eeeeee

5

3

�������3

3

1

������

�4XXXXXXXXXXXX

6

,,,,,,,,

5

������

������4

QQQQQ

2

Figura 4.3: Topología de una red con diez nodos

Tabla de vecindades

Nodo Vecinos Frecuencia1 2, 5, 6 12 3, 4, 5 53 2, 4, 5 34 2, 3, 5 65 2, 4, 6 66 4, 5, 7 57 6, 8, 10 58 4, 6, 7 49 7, 8, 10 2

10 7,8, 9 3

Tabla de frecuencias

J Sj

1 12 13 24 15 36 2

De la tabla de vecindades se obtiene una tabla de frecuencias que será uti-lizada para calcular el promedio ponderado de vecindades. La tabla de fre-cuencias contiene las frecuencias J observadas en la tabla de vecindades y elnúmero de veces, Sj , en que se observó ese valor de frecuencia. El promedioponderado se calcula directamente a partir de la tabla:

v̄ =

⌊1× 1 + 2× 1 + 3× 2 + 4× 1 + 5× 3 + 6× 2

10

⌋+ 1 = 5

Los candidatos potenciales son aquellos con un número de vecinos mayor oigual a 5, es decir, los nodos 2, 6, 7, 4 y 5.

Si se encuentra que algunos concentradores están demasiado cerca o si hay sobrecargaal agregar el análisis de tráfico, a partir de este diseño de base se pueden hacer reconfigu-raciones.

4.2.2. Asignación de nodos a concentradores

Una vez identificada la localización de los concentradores potenciales, deberá deci-dirse cómo interconectar los nodos terminales con estos concentradores. Dado que en

Diseño y Arquitectura de Redes Telemáticas 93

Page 104: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

general se da prioridad a minimizar el costo debido a la potencialmente gran cantidad deusuarios (o nodos) que deben interconectarse, se busca que cada nodo se conecte a uno ysolamente un concentrador, ignorando enlaces redundantes.

Básicamente, se evalúa la conveniencia de cada concentrador potencial calculando elcosto o la reducción que se tiene eliminando cada uno de ellos. Para esto, se han propuestovarias heurísticas, entre las más populares están:

Greedy. Cada terminal se conecta a su concentrador más cercano. Si ya no tiene ca-pacidad (en nuestro caso, si ha alcanzado la conectividad K), la terminal se conectaal mejor disponible.

Add o de construcción. Todos los nodos se conectan a un solo concentrador. Sevan agregando concentradores que prometan ahorros en costo de conectividad y seconectan terminales a ellos hasta que no se justifique agregar más.

Drop o de eliminación. Se inicia con cada nodo conectado al concentrador queminimiza el costo de la conexión. Se eliminan concentradores hasta que ningunopueda eliminarse.

4.2.3. Topología de nodos a concentrador

Ya se ha decidido qué concentradores se retienen y qué nodos deben conectarse a cadauno. Solo falta decidir cómo deben conectarse los nodos terminales al concentrador. Latopología más sencilla es la estrella, pero puede no ser la configuración más eficiente,por lo que deben investigarse alternativas en las que algunos enlaces pueden compartirsetransportando el tráfico de varios nodos.

Este tipo de problemas para obtener las trayectorias mínimas entre un conjunto denodos es bien conocido en redes de comunicaciones y en logística. Sus soluciones con-sisten en encontrar un árbol de expansión mínimo (minimum spanning tree, MST), esdecir, aquél en el que la suma de los brazos es mínima. A continuación se presentarán dosejemplos de estos algoritmos. Ellos dan una solución mínima cuando se trabaja sin restric-ciones, es decir, sin considerar las capacidades de los enlaces. Al incluir esta restricción,los métodos pueden proporcionar resultados ligeramente distintos.

Con el fin de ejemplificar los dos algoritmos, se considerará una red que tiene ochonodos, de los cuales el primero es es concentrador. Los “costos” de conexión entre losdistintos nodos, son los que se muestran en la matriz de costos.

El costo aquí puede ser cualquier métrica: costo de instalación, longitud de cableado,etc. Las métricas de desempeño y de número de saltos son costos más relevantes en redesWAN.

Diseño y Arquitectura de Redes Telemáticas 94

Page 105: Diseño y Arquitectura de Redes Telemáticas

4.2. DISEÑO DE LA CAPA DE ACCESO

Matriz de costos cij1 2 3 4 5 6 7 8

1 0 2 52 13 45 15 58 592 2 0 52 14 43 16 58 623 52 52 0 60 85 41 23 554 13 14 60 0 50 18 72 505 45 43 85 50 0 59 81 956 15 16 41 18 59 0 55 427 58 58 23 72 81 55 0 788 59 62 55 50 95 42 78 0

Algoritmo de Esau-Williams

El método de Esau-Willimas da muy buenos resultados aún para redes de gran tamañoy ha sido la base de muchas estrategias contemporáneas. Consiste en los pasos:

1. Se inicia con todos los nodos conectados en estrella con el concentrador.

2. Se calcula una matriz de diferencias dij = cij− ci1, es decir, la diferencia resultantede conectar el nodo i al nodo j en vez de conectarlo al concentrador (nodo 1).

3. Las entradas con valores negativos indican conexiones alternativas más económicaspara esos concentradores.

4. Se empieza por seleccionar los valores más negativos y se continúa hasta agotarlos.

EJEMPLO 4.2. A partir de la matriz de costos se calcula la matriz de dife-rencias de la siguiente manera:

d2−3 = c2−3 − c2−1 = 52− 2 = 50; d2−4 = c2−4 − c2−1 = 14− 2 = 12; . . .

d3−2 = c3−2 − c3−1 = 52− 52 = 0; d3−4 = c3−4 − c3−1 = 60− 52 = 8; . . .

La matriz de diferencias resultante para la configuración de referencia en estasección es:

Matriz de diferencias dij1 2 3 4 5 6 7 8

2 0 - 50 12 41 14 56 603 0 0 - 8 33 -11 -29 34 0 1 47 - 37 5 59 375 0 -2 40 5 - 14 36 506 0 1 26 3 44 - 40 277 0 0 -35 14 23 -3 - 208 0 3 -4 -9 36 -17 19 -

Diseño y Arquitectura de Redes Telemáticas 95

Page 106: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

7

3

6 8

2

5

4

1

Paso 0

""

PPP

�����

���

QQQQ

7

3

6 8

2

5

4

1

Paso 1

""

PPP

�����

���

BBB

7

3

6 8

2

5

4

1

Paso 2

""

PPP

�����

���

BBB

Figura 4.4: Algoritmo Esau-Williams. Pasos 0 a 2 del ejemplo

El proceso inicia conectando todos los nodos al concentrador, como se mues-tra en el Paso 0 de la figura ??.

En la matriz de diferencias se busca el enlace con el valor más negativo, esdecir, aquél que representa el mayor ahorro. Claramente se trata del enlace7 ↔ 3 con un “ahorro” de 35: conectar el nodo 7 al 3 en vez de conectarlodirectamente al concentrador genera un ahorro de 35 unidades, por lo que semodifica la topología como aparece en el Paso 1 de la figura ??.

Para el siguiente paso se consulta nuevamente la matriz de diferencias. Elsiguiente número más negativo es el que corresponde al enlace 3↔ 7 con unvalor de 29. Este enlace no se toma en cuenta pues ya están conectados losnodos 7 y 3. Al buscar el siguiente enlace, se selecciona el 6↔ 8 con un valorde 17, modificando la topología como aparece en el Paso 2 de la figura ??.

En el paso 3, la matriz de diferencias indica conectar el nodos 3 al 6 y final-mente, el 5 al 2, dejando como resultado la topología que aparece a la derechade la figura ??.

7

3

6 8

2

5

4

1

Paso 3

""

PPP

�����

���

BBB

7

3

6 8

2

5

4

1

Paso 4

""

PPP

��

���

BBB

Figura 4.5: Algoritmo Esau-Williams. Pasos 3 y 4 del ejemplo

El costo de la topología de estrella era de 244; el costo de la topología finales de 179.

Diseño y Arquitectura de Redes Telemáticas 96

Page 107: Diseño y Arquitectura de Redes Telemáticas

4.2. DISEÑO DE LA CAPA DE ACCESO

Algoritmo de Kruskal

El método de Kruskal es bastante sencillo pero se ha observado que para grandes redescon restricciones, las soluciones a las que se llega suelen estar alejadas de la topologíaóptima. Este método comienza con todos los nodos desconectados y consiste en:

1. Se ordenan los enlaces de la matriz según su costo.

2. Se seleccionan los enlaces de menor a mayor costo y se van trazando en el diagrama.Si la utilización de un enlace genera un lazo, éste se rechaza.

3. Se continua seleccionando enlaces hasta que todos los nodos estén conectados.

EJEMPLO 4.3. A partir de la matriz de costos que se presentó en la pági-na 95, la relación de enlaces ordenados por costo es la siguiente:

Enlace Costo Enlace Costo1↔ 2 2 6↔ 4 181↔ 4 13 3↔ 7 232↔ 4 14 3↔ 6 411↔ 6 15 6↔ 8 422↔ 6 16 2↔ 5 43

Se selecciona el primer enlace y se conecta el nodo 2 al concentrador. Deigual forma, en el siguiente paso se conecta el nodo 4 al concentrador. Elsiguiente enlace a considerar sería entre los nodos 2 y 4 pero esto generaríaun lazo, por lo que se ignora; se toma el enlace conectando el nodo 6 alconcentrador como se muestra en la figura ??.

7

3

6 8

2

5

4

1

Paso 1

""

7

3

6 8

2

5

4

1

Paso 2

""

PPP

7

3

6 8

2

5

4

1""

PPP

���

Paso 3

Figura 4.6: Algoritmo Kruskal. Pasos 1 a 3 del ejemplo

Los enlaces 2↔ 6, y 6↔ 4 también formarían un lazo y no son tomados encuenta. Siguiendo con la tabla, se conectan los enlaces 3↔ 7, 3↔ 6, 6↔ 8y 5 ↔ 2. Con esto se han conectado todos los nodos, como se muestra en lafigura ??, que coincide con la topología de la figura ??.

Diseño y Arquitectura de Redes Telemáticas 97

Page 108: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

7

3

6 8

2

5

4

1

Paso 1

""

PPP

���

BBB

7

3

6 8

2

5

4

1

Paso 2

""

PPP

���

BBB

7

3

6 8

2

5

4

1""

PPP

��

���

BBB

Paso 3

Figura 4.7: Algoritmo Kruskal. Pasos 4, 6 y 7 del ejemplo

Consideraciones de tráfico

En los ejemplos de los algoritmos anteriores no se tomaron en cuenta restricciones. Ensituaciones más reales hay que tomar en cuenta varias restricciones, como el hecho de queno siempre están disponibles las conexiones entre dos nodos cualesquiera. Una restricciónmás importante consiste en reconocer que no se pueden agregar nodos indefinidamenteen un enlace multilínea sin tomar en cuenta la carga que cada nodo irá agregando a la red.Eventualmente la capacidad del enlace se verá rebasada.

Si ese fuera el caso, al aplicar las heurísticas de Esau-Williams o de Kruskal, la co-nexión que violara la restricción de capacidad tendría que ser ignorada y se pasaría alsiguiente punto.

EJEMPLO 4.4. Retomando el ejemplo del algoritmo Esau-Williams, se con-siderará que la capacidad máxima de cualquier enlace es de 19 unidades (pa-quetes, tramas, kBytes, . . . ) y que cada nodo contribuye con la carga que seindica en la tabla. Al querer agregar el tráfico de los nodos 7 y 3 al nodo 6(paso 3 en la figura ??), la capacidad del enlace 6 ↔ 1 se rebasaría, por loque la conexión 3↔ 6 no se realiza. La topología resultante se muestra en lafigura ??.

Nodo Tráfico2 143 124 135 66 77 68 6

7

3

6 8

2

5

4

1""

PPP

�����

���

BBB

Paso 4

Figura 4.8: Algoritmo con restricciones de tráfico. Configuración resultante

Diseño y Arquitectura de Redes Telemáticas 98

Page 109: Diseño y Arquitectura de Redes Telemáticas

4.3. CAPA DE DISTRIBUCIÓN

4.3. Capa de distribución

La capa de acceso y el núcleo de la red tienen objetivos muy distintos. La primerada conectividad a los equipos terminales de los usuarios al menor costo posible. Por suparte, el núcleo de la red tiene por objeto encaminar los paquetes con la mayor eficienciaposible.

La capa de distribución funciona como un punto de demarcación entre estas dos. Suprincipal tarea es ofrecer los servicios de conectividad del núcleo a la red de acceso, conbase en las políticas de la organización.

Los dispositivos en esta capa son los mejores candidatos para aplicar las políticas dela organización, pues en ella se interconectan las redes locales, concentrando el tráfico delos usuarios, y se libera a los dispositivos en el núcleo de realizar funciones ajenas a laconmutación eficiente de paquetes.

Los requerimientos de disponibilidad en la capa de distribución empiezan a cobrarimportancia, pues el fallo de un equipo en esta capa puede aislar una sección muy grandede la red. Frecuentemente se usan equipos redundantes y los nodos de acceso se conectana ambos como se muestra en la figura 4.2.

Las funciones específicas que realiza la capa de distribución dependen, desde luego,del tamaño y complejidad de la red, así como de la estrategia de la organización. Lalista que se muestra a continuación ejemplifica algunas de estas funciones, muchas de lascuales serán descritas con mayor detalle en capítulos subsecuentes.

Enrutamiento entre VLANs . Si en la empresa se utilizan redes locales virtuales, lacapa de distribución es un punto natural de interconexión, y de enrutamiento entreellas.

Servidores de configuración . En redes de tamaño pequeño y mediano, en las que en lacapa de acceso hay unas cuantas redes locales, servidores de configuración comoDHCP, WINS, LDAP pueden colocarse en esta capa.

Adaptación de protocolos de enrutamiento . Frecuentemente los enrutadores en la ca-pa de distribución deben seguir dos esquemas distintos de protocolos de enruta-miento: uno hacia la red de acceso y otro hacia el núcleo. En redes pequeñas, en lared de acceso suele seguirse un enrutamiento estático y en el núcleo uno dinámicointerno (por ejemplo, OSPF). En redes medianas y grandes, la red de acceso sueletener enrutamiento dinámico interno y hacia el núcleo puede utilizarse un protocolode enrutamiento externo (por ejemplo, BGP).

Control de desempeño . En redes pequeñas, esta capa rompe los dominios de difusiónde las redes locales, limitando el tráfico entre ellas.

A través de la configuración de las tablas y políticas de enrutamiento, se controla elflujo de tráfico desde y hacia el núcleo de la red. Además, si la política de direccio-namiento lo permite, es en esta capa en la que se puede realizar la sumarización de

Diseño y Arquitectura de Redes Telemáticas 99

Page 110: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

rutas para disminuir el tamaño de las tablas de enrutamiento en los dispositivos delnúcleo.

Por otra parte, los dispositivos en esta capa pueden implementar mecanismos dife-renciados de asignación de ancho de banda por prioridades y conformado de tráfico(traffic shaping) para cumplir con los acuerdos de servicio y no rebasar las capaci-dades del núcleo.

Seguridad y auditoría . Los dispositvos en la capa de distribución pueden filtrar el trá-fico entre las capas de acceso y el núcleo para aplicar las políticas de seguridad dela organización. También es en este nivel el que se puede realizar la traducción dedirecciones entre las redes internas (en la capa de acceso) y el núcleo.

Así mismo, la capa de distribución es un punto ideal para monitorear, auditar ycontabilizar el tráfico que fluye por la red.

4.4. Diseño de la red dorsal

La función principal de red dorsal es interconectar eficientemente los sitios (es decir,las distintas redes de acceso) de la organización.

A diferencia de la red de acceso, en esta capa todos los “nodos” (es decir, los sitios)pueden intercambiar tráfico entre sí, por lo que los dos criterios fundamentales dediseño para la red dorsal son la eficiencia y la tolerancia a fallos.

Por ello, todas las funciones lógicas relacionadas con las políticas de la organizaciónhan sido relegadas a la capa de distribución. Los dispositivos a seleccionar para el nú-cleo de la red deben tener una muy alta disponibilidad y capacidad de conmutación depaquetes.

Un fallo en la red dorsal afecta a una gran parte de los usuarios, por lo que se buscadiseñar una topología redundante (ver figura 4.9) capaz de soportar un cierto número defallos y de adaptarse a los cambios rápidamente.

Figura 4.9: Diseño de la red dorsal

Diseño y Arquitectura de Redes Telemáticas 100

Page 111: Diseño y Arquitectura de Redes Telemáticas

4.4. DISEÑO DE LA RED DORSAL

Se debe tratar limitar el tamaño y mantener la consistencia del núcleo de la red. Estopermitirá predecir el desempeño, detectar rápidamente fallos y en general, simplificar laadministración.

En un campus, el núcleo de la red interconecta las redes LAN que ya han sido agrega-das en la capa de distribución. En una red WAN, esta capa típicamente utiliza los serviciosde un proveedor de transporte para interconectar los sitios entre sí.

Entre los servicios propuestos por los operadores en la actualidad para diseñar la reddorsal se encuentran:

X.25

Frame Relay

ATM

MPLS

Enlaces dedicados

Redes virtuales privadas en Internet (VPN)

La selección del servicio particular dependerá de su disponibilidad en todas las zo-nas que deban interconectarse así como de los requerimientos de diseño (desempeño,seguridad, costo, etc.). En la actualidad en México, como en muchas partes del mundo,prácticamente han desaparecido los servicios de X.25 y ATM y han sido sustituidos porFrame Relay (se estima que en 2003, el 80 % de los enlaces WAN eran Frame Relay) ymás recientemente, por MPLS y por VPNs, que se estudiarán con mayor detalle en capí-tulos posteriores. Salvo casos muy particulares, los enlaces privados también han perdidopopularidad debido a su alto costo.

Para redes pequeñas, las topologías de malla, de estrella y combinaciones de éstas sehan utilizado con regularidad. Sin embargo, ya se ha mencionado que estas topologías nopodrían satisfacer algunos requerimientos críticos para redes grandes.

4.4.1. Diseño de la topología

Típicamente, diseñar la topología del núcleo implica encontrar un punto de equilibrioentre los requerimientos de costo, disponibilidad y desempeño de la red. Nuevamente, seha encontrado que este es un problema de gran complejidad para el que se han propuestoalgunas heurísticas iterativas de diseño. Un ejemplo clásico sería el siguiente:

1. Se calcula una matriz de tráfico entre los distintos sitios;

2. se propone una topología inicial (con algún algoritmo);

3. a partir de la matriz de tráfico, se asigna tráfico a los enlaces;

4. se determina la capacidad de los enlaces y se les asigna un costo;

5. se introduce una perturbación que altere la topología y se regresa al punto 3.

Diseño y Arquitectura de Redes Telemáticas 101

Page 112: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

6. Cuando se han evaluado todas las posibilidades (o tras un determinado número deiteraciones, se retiene la topología con el costo menor.

Topológicamente, el diseño de la red dorsal debe cumplir con los requerimientos dedisponibilidad. Esto implica que la topología debe tener k trayectorias disjuntas entre dosnodos cualesquiera si se desea que la red tolere k − 1 fallos y siga conectada2.

Heurística de Steiglitz-Weiner-Kleitman

El problema de encontrar una red k-conectada de costo mínimo es conocido como elproblema de diseño de redes sobrevientes o como el problema generalizado de los árbolesde Steiner. La heurística de Steiglitz, Weiner y Kleitman permite encontrar una soluciónlocal para este problema.

La heurística está basada en el teorema de Whitney:

Una condición necesaria para que una red sea k-conectada, es que el gradode sus nodos (el número de interfaces en nuestro caso), sea mayor o igual ak.

Funciona de la siguiente manera:

1. Se enumeran los nodos de manera aleatoria. Asignar identificadores aleatorios per-mitirá crear fácilmente nuevas topologías al tratar de hallar soluciones con costomenor.

2. Se asigna a todos los nodos un déficit igual al grado k deseado. Este déficit es elnúmero de interfaces que no han sido asignadas a enlaces hacia otros nodos.

3. Se selecciona el nodo con el déficit más alto. Si hay varios candidatos, se seleccionael que tiene el menor identificador.

4. Se enlaza este nodo con el nodo con el mayor déficit entre los no adyacentes. Sihay varios candidatos, se selecciona el más cercano (menor costo). Si hay varioscandidatos, se selecciona el que tiene el identificador menor. Al hacer el enlace, sedecrementa el déficit en cada uno de estos nodos.

5. Se continúa desde el punto 3 hasta que todos los nodos tengan un déficit menoro igual a cero. Algunos nodos pueden tener un déficit negativo, lo que se ajustaráposteriormente.

2Una red está conectada si existe una trayectoria entre cualquier par de nodos. Se dice que la red esde grado k o está k-conectada si existen k trayectorias disjuntas entre cualquier par de nodos, donde dostrayectorias son disjuntas si no tienen ningún enlace o nodo en común.

Diseño y Arquitectura de Redes Telemáticas 102

Page 113: Diseño y Arquitectura de Redes Telemáticas

4.4. DISEÑO DE LA RED DORSAL

EJEMPLO 4.5. En la figura ?? se presenta paso a paso la heurística de Stieglitz-Weiner-Kleitman para una red de 5 nodos con una tolerancia a 2 fallos (3-conectada).

Los números al interior de los nodos representan su déficit. Los númerosen el exterior representan su identificador aleatorio. En este caso, se hasupuesto que el costo de los enlaces es el mismo para cualquier par de nodos.

1

2

3

45 Paso 0

3

3

3

33

1

2

3

45 Paso 1

2

2

3

33

QQQQ

1

2

3

45 Paso 2

2

2

2

23

QQQQ

SSS

1

2

3

45 Paso 3

1

2

2

22

QQQQ

SSS

���

1

2

3

45 Paso 4

1

1

1

22

QQQQ

SSS

���

���� 1

2

3

45 Paso 5

1

1

1

11

QQQQ

SSS

���

����

1

2

3

45 Paso 6

0

1

0

11

QQQQ

SSS

���

���� 1

2

3

45 Paso 7

0

0

0

01

QQQQ

SSS

���

����

�����

1

2

3

45 Paso 8

0

-1

0

00

QQQQ

SSS

���

����

�����

LLLLL

Figura 4.10: Algoritmo Stieglitz-Weiner-Kleitman

Asignación de capacidad

Si bien la asignación de capacidad de los enlaces es una actividad relacionada con eldiseño físico de la red, en la red dorsal éste es un proceso complejo e iterativo que influyeen la topología final, por lo que en esta sección se introducen los conceptos básicos deasignación de capacidad.

El punto de partida para dimensionar los enlaces de la red dorsal consiste en estimar lacantidad de tráfico que cada nodo inyectará hacia el núcleo. Para ello, es necesario identi-ficar qué porcentaje del tráfico generado en las redes de acceso de cada nodo es local y qué

Diseño y Arquitectura de Redes Telemáticas 103

Page 114: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

porcentaje viaja hacia otros nodos (hacia otras redes de acceso). Esta información permitecrear una matriz de tráfico con una aproximación del volumen de tráfico intercambiadoentre nodos.

Una vez conocidos los volumenes de tráfico, es necesario identificar las trayectoriasque recorrerán los flujos en la topología obtenida. En general, estas trayectorias estarándeterminadas por las políticas y los protocolos de enrutamiento, y por la dinámica de lared. Si el número de conexiones es relativamente alto, y los enlaces tienen una métrica decosto similar, es posible suponer que las rutas seleccionadas serán las de menor costo.

Sin embargo, por razones que serán explicadas en capítulos posteriores, en redes demediana complejidad la selección de rutas se establece con anterioridad mediante un pro-ceso de Ingeniería de Tráfico en el que se configura una red superpuesta sobre la que setiene un mejor control del tráfico en el núcleo de la red.

Finalmente, debe tomarse en cuenta que, si el criterio central de diseño es la toleranciaa fallas, entonces deberá asignarse un factor de sobrecarga que permita soportar el tráficoexcedente en caso de que un enlace (una trayectoria) falle y su carga sea repartida entrelos demás. Para soportar una falla, el factor de sobrecarga es:

Lf = U − U

N,

donde N es el número de enlaces y U es la utilización máxima deseable con la que sedimensionan los enlaces.

EJEMPLO 4.6. Para una red de grado 4, en la que se desea dejar libre un20 % de la capacidad de los enlaces en el caso de una falla, el dimensiona-miento de los flujos no debe rebasar el 60 % de utilización:

Lf = 80 %− 80 %

4= 60 %

En algunas ocasiones se tiene una idea general de los volúmenes de información ge-nerados en las redes de acceso pero se desconocen los patrones de tráfico detallados.En estos casos, no queda más remedio que recurrir a generalizaciones y suponer quelos volúmenes de tráfico se concentrarán en los repositorios de información, o que sedistribuirán uniformemente entre las redes de acceso.

Para apoyar el diseño de la red en estas circunstancias, se puede utilizar la siguientefórmula de equilibrio de tráfico. El tráfico que entra a un nodo del núcleo debe ser igual ala cantidad de tráfico que sale del mismo:

ΣNai=1v

ia × U i

a = Σkbj=1v

jb × U

jb ,

donde Na es el número de redes de acceso que llegan a un nodo, via es la capacidad delenlace de la i-ésima red con una utilización media de U i

a, kb es el grado del nodo en elnúcleo y vjb la capacidad del j-ésimo enlace con una utilización media de U j

b .

Diseño y Arquitectura de Redes Telemáticas 104

Page 115: Diseño y Arquitectura de Redes Telemáticas

4.4. DISEÑO DE LA RED DORSAL

EJEMPLO 4.7. Considere una red nacional que tiene 1,000 sitios (o redes deacceso). Los usuarios generan en promedio 950GB de datos por día hacia losdemás sitios. No hay elementos para determinar cómo se distribuye este vo-lumen de tráfico entre las distintas redes de acceso. Lo que sí se ha estimado,es que el 20 % de este volumen se genera durante la hora de mayor actividad(la hora pico).

Todos los sitios se conectan a nodos en el núcleo por medio de enlaces E1.Por políticas de la empresa, los enlaces en el núcleo también son E1 y comocriterio de diseño, estos enlaces no deben rebasar el 50 % de utilización encondiciones normales de operación (es decir, sin tomar en cuenta fallos en lared). Se busca una red dorsal de grado 4. ¿Cuántos nodos en el núcleo debenconsiderarse?

En primer término, hay que determinar cuál es la utilización de los enlacesde acceso:

Ua =0.2(950GB/dia)

1, 000× 8 b

3, 600 s× 1

2.048Mb/s= 20.6 %

Ahora se puede estimar el número de enlaces por nodo:

Na × va × Ua = kb × vb × Ub

Na =4× 2.048MB/s× 0.5

2.048Mb/s× 0.206

= 9.7⇒ 9

Por consiguiente, se necesitarán 1000/9 ≈ 112 nodos.

Perturbación de la topología

La topología obtenida puede no ser la mejor aún si cumple con los criterios de costoy desempeño. Para generar otras topologías, se repite el proceso introduciendo perturba-ciones controladas generando nuevos identificadores para los nodos.

Más importante aún, la topología inicial fue diseñada respondiendo a criterios de co-nectividad sin tomar en cuenta el tráfico en la red. Si se tiene un conocimiento generalde los flujos, la topología resultante puede modificarse atendiendo a criterios como lossiguientes:

Nodos que intercambien altos volúmenes de información deben tener enlaces co-nectados directamente.

Enlaces con muy poca utilización pueden ser eliminados y su tráfico asignado aenlaces cercanos.

Enlaces con tecnologías muy costosas también pueden ser eliminados.

Diseño y Arquitectura de Redes Telemáticas 105

Page 116: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

4.5. Diseño basado en bloques modulares

En las secciones anteriores se han presentado los conceptos y los beneficios de con-tar con un diseño jerárquico de tres capas y se han mostrado algunos algoritmos parasatisfacer los requerimientos de diseño en las capas de acceso y dorsal.

Otra característica que un buen diseño de redes debe cumplir es su modularidad. Sobretodo en redes medianas y grandes, un diseño modular simplifica las etapas de desarrollo ydespliegue, facilita el mantenimiento de la red, reduce la probabilidad de dejar pasar erro-res no detectados, ofrece un buen rendimiento, y asegura la escalabilidad de la solución.

El diseño modular consiste en contar con bloques básicos de módulos (o componen-tes) típicos en la red de una organización, por ejemplo, bloques de granjas de servidores,de redes SAN, de redes locales, de acceso al núcleo, etc. Sobre esos bloques básicos, seharán pequeñas modificaciones para satisfacer los requerimientos específicos de diseño,y se interconectarán para integrar la red.

Dada su gran popularidad, en los siguientes párrafos se presentará el enfoque de dise-ño modular para una red de campus de tamaño medio.

Bloque básico de acceso Excepto en redes locales inalámbricas y en algunos nichosmuy específicos, el uso de concentradores en las redes locales ha disminuido dramática-mente. Las ventajas de seguridad y de mayor desempeño, aunado a una gran reducción enel costo por puerto de los conmutadores, han hecho que estos dispositivos sean los másutilizados en la actualidad, como se muestra en la figura 4.11.

Figura 4.11: Diseño modular. Bloque básico de acceso

Bloque básico de distribución En la figura 4.12 se muestra un bloque genérico de lacapa de distribución. Dependiendo de las funcionalidades deseadas, y del tamaño de lared, en el bloque de distribución pueden encontrarse conmutadores, enrutadores o ambos.En la figura mostrada, se observan conmutadores a los que se conectan los conmutadoresde la red de acceso. Las funcionalidades de la capa de distribución se ejecutan en losenrutadores.

Diseño y Arquitectura de Redes Telemáticas 106

Page 117: Diseño y Arquitectura de Redes Telemáticas

4.6. TOPOLOGÍAS CON REDUNDANCIA

Figura 4.12: Diseño modular. Bloque básico de distribución

Bloque básico de red dorsal En un campus, como en una red local grande, el núcleode la red estará conformado por conmutadores de alto desempeño, como se muestra en lafigura 4.13. En este caso particular, ni siquiera las funciones de enrutamiento se efectúanen el núcleo. Estas fueron delegadas a la capa de distribución.

Figura 4.13: Diseño modular. Bloque básico de la red dorsal

Con el diseño modular, construir una solución para una red consiste en interconec-tar los bloques básicos. Por ejemplo, en la figura 4.14 se muestra del lado izquierdo unasolución para una red de campus genérica. Para satisfacer los requerimientos de disponi-bilidad, esta misma red puede robustecerse como se muestra en el diagrama de la derecha.La siguiente sección presenta algunos conceptos de topologías redundantes.

4.6. Topologías con redundancia

Con el fin de satisfacer los requerimientos de disponibilidad, el diseño de la red debecontar un cierto número de componentes redundantes que permitan asegurar, al menos, lacontinuidad de las operaciones de misión crítica de la organización.

En las secciones anteriores ya se han introducido enlaces redundantes para tolerar fa-llos sobre todo en el núcleo de la red. Sin embargo, para que la infraestructura continúe

Diseño y Arquitectura de Redes Telemáticas 107

Page 118: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

Figura 4.14: Red genérica modular sin y con enlaces redundantes

operando, el diseño de la red también debe incluir redundancia en servidores, en enru-tadores y nodos de conmutación, en los accesos a internet, y hasta en los sistemas dealimentación de energía eléctrica.

La redundancia en equipos y enlaces incide directamente en el costo de la infraes-tructura; además, genera una red mucho más compleja de administrar, sobre todo en laconfiguración de políticas de enrutamiento y en la gestión y asignación de direcciones.

El nivel de redundancia deseado debe elegirse con cuidado poniendo énfasis en elsoporte a operaciones de misión crítica.Por otra parte, una duplicación cuidadosa de componentes en la infraestructura de reden general permite realizar un balanceo de cargas aumentando así el desempeño totalde la red.

Si los dispositivos redundantes no forman parte de la operación cotidiana de la red,resulta primordial garantizar que:

está definido y funciona apropiadamente el mecanismo para conmutar a los equiposde respaldo;

el tiempo de conmutación (llamado también tiempo de convergencia) a los equi-pos de respaldo está dentro de los parámetros aceptables para evitar caídas de lasaplicaciones y servicios;

la capacidad de operación en el respaldo es suficiente para soportar los serviciosprincipales. En este caso, se debe contar con mecanismos que filtren el tráfico paradar prioridad a los flujos de misión crítica;

los equipos y enlaces de respaldo son, efectivamente, independientes de la red enoperación;

la red de respaldo es probada periódicamente para asegurar su funcionamiento. Serecomienda que por lo menos dos veces al año se realicen simulacros de fallos enlos que se activen los dispositivos de respaldo.

Diseño y Arquitectura de Redes Telemáticas 108

Page 119: Diseño y Arquitectura de Redes Telemáticas

4.6. TOPOLOGÍAS CON REDUNDANCIA

Caso de estudio.- Como muchas organizaciones, una empresa del sector fi-nanciero contaba con enlaces de microondas para interconectar sus sucursalescon el centro de cómputo en la oficina matriz. Como respaldo, cada sucursaltenía una línea telefónica con un módem de 14.4 a 33 kb/s. Esta configura-ción funcionaba adecuadamente cuando los sistemas de la empresa tenían unmodelo centralizado en el que las sucursales sólo ejecutaban aplicaciones determinal virtual y a través de los enlaces se intercambiaban pantallas de textoúnicamente.

En un momento determinado, el área informática, la cual estaba completa-mente desvinculada del área de telecomunicaciones, decidió actualizar sussistemas y migrar a un modelo de varias capas. Ahora las aplicaciones en lassucursales ejecutaban clientes robustos con interfaces gráficas y contenidosmás complejos.

Con el cambio, el volumen de tráfico entre el centro de datos y las sucursalesaumentó sustancialmente. Este cambio sí fue notificado al área de teleco-municaciones y se aumentó la capacidad de los enlaces de microondas. Encambio, jamás se consideró la actualización en los enlaces de respaldo. Elprimer incidente posterior a la migración resultó caótico, pues el respaldo te-lefónico era totalmente insuficiente hasta para soportar las aplicaciones másesenciales.

Fue necesario activar un plan de emergencia adquiriendo enlaces de bandaancha o enlaces privados –que no estaban contemplados en el presupuestooriginal– y hacer profundas adecuaciones a la infraestructura de red para so-portar la nueva topología.

Servidores y nodos

Existen algunos servicios, como el Servidor de Nombres de Dominio (DNS), diseña-dos específicamente para trabajar con servidores redundantes. Desgraciadamente ésta esla excepción, y en general, el balanceo de cargas no es una tarea trivial: en los servidoresse requiere de reglas especiales y de un cierto nivel de sofisticación para llevarlo a caboexitosamente.

Si la duplicación de servidores de aplicaciones, de archivos, de bases de datos, etc.resulta muy costosa, al menos se debe tratar de que estos servidores cuenten con discosRAID (Redundant Array of Inexpensive Disks) con el nivel de redundancia apropiado.

En los nodos de conmutación, uno de los componentes que más fallos presenta es lafuente de alimentación, muchas veces debido a problemas en el sistema de suministro.Por ello, es común que los conmutadores y enrutadores de alto desempeño cuenten confuentes de alimentación redundantes, las cuales deben estar conectadas a una línea dealimentación distinta.

Diseño y Arquitectura de Redes Telemáticas 109

Page 120: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

Enlaces

Aunque los enrutadores conozcan varias trayectorias hacia un mismo destino, normal-mente no distribuyen el tráfico entre ellas a menos que todas las trayectorias cuenten conla misma métrica. De no ser así, los enrutadores deben configurarse específicamente parapermitir el balanceo de cargas.

En las redes locales, el mecanismo de spanning tree en los conmutadores bloquea elbalanceo de cargas al inhibir la existencia de varias trayectorias entre dos dispositivos.

Gateway por omisión

Cuando un dispositivo desea establecer una comunicación fuera de su red local, mandasus paquetes a un enrutador quien los redirige hacia la trayectoria que los conducirá aldestino final. Este enrutador se conoce como el gateway por omisión y, típicamente, sudirección está configurada en las computadoras de la red local.

Este gateway es un punto vulnerable: si falla, todos los dispositivos en la red localpierden conexión con el exterior. Si se agrega un segundo enrutador como respaldo, encaso de detectar una falla todos los equipos en la red local deberán reconfigurarse con ladirección del enrutador de respaldo, lo cual es inaceptable en redes de mediano tamaño.

Se han propuesto varias soluciones a este problema. En primer lugar, los dispositivospodrían ejecutar un protocolo de enrutamiento interno (como RIP u OSPF) y recibir asílos anuncios del gateway por omisión y del respaldo. En este caso, el protocolo en las es-taciones debe ejecutarse en modo pasivo, es decir, atendiendo únicamente a los anunciosrecibidos pero sin publicar sus tablas de ruteo para reducir el tráfico en la red. Desgracia-damente esta solución presenta varios problemas:

aumenta la complejidad para administrar los dispositivos;

los protocolos de ruteo consumen recursos;

el tiempo para reconfigurar un dispositivo depende de la frecuencia con la que seanuncien las tablas en la red, el cual depende del protocolo utilizado. Este tiempopuede ser lo bastante grande como para no pasar desapercibido;

se presta a ataques de seguridad pues un intruso o una máquina comprometida puedeanunciarse como enrutador por omisión.

Router Discovery Protocol, RDP, es otra solución basada en la difusión periódica demensajes ICMP especiales por parte de los enrutadores. Si un dispositivo detecta que unmensaje no ha sido recibido, supone que el gateway ha fallado y puede enviar inmediata-mente otro mensaje ICMP solicitando que un (posiblemente nuevo) enrutador se anuncie.Esta solución reduce algunos de los problemas anteriores, pero sigue siendo vulnerable alos ataques de seguridad, por lo que ha sido muy poco implementada. De hecho, hoy serecomienda fuertemente ignorar los mensajes ICMP relacionados con este protocolo.

Diseño y Arquitectura de Redes Telemáticas 110

Page 121: Diseño y Arquitectura de Redes Telemáticas

4.6. TOPOLOGÍAS CON REDUNDANCIA

La solución más recomendada en la actualidad para ofrecer redundancia en el gate-way por omisión es el protocolo VRRP (Virtual Router Redundancy Protocol), tambiénconocido como enrutador fantasma, o la variante de Cisco: HSRP (Hot Standby RouterProtocol).

Figura 4.15: Configuración de enrutador fantasma

Observe la figura 4.15. Se define un enrutador virtual con una dirección MAC y unadirección IP determinadas. El gateway por omisión responde a los mensajes enviados aestas direcciones virtuales y también envía al enrutador de respaldo mensajes periódica-mente indicando que se encuentra activo. Si el enrutador de respaldo detecta que estosmensajes han dejado de enviarse, inmediatamente toma el papel del enrutador virtual, sinque los dispositivos en la red detecten el cambio.

El único problema con esta solución es que el enrutador de respaldo no puede serutilizado para balancear la carga en la red local, aunque hay protocolos propietarios quelo permiten.

Salida a internet

Al definir trayectorias redundantes, hay que poner especial atención al enlace entrela empresa y el punto de presencia (PoP) del proveedor de acceso (ISP). Esta liga esnormalmente la más débil de la red.

Dada la creciente importancia que han adquirido los accesos a Internet, una organiza-ción puede optar por alguna de las opciones que se muestran en la figura 4.16.

Los principales elementos a considerar en estas configuraciones son la seguridad adi-cional de contar con más de un proveedor de acceso contra la complejidad que esto im-plica pues en general no es trivial definir, negociar y verificar un contrato de servicio pararedes de tamaño medio.

En las primeras dos opciones se tiene la ventaja de trabajar con un solo proveedor,con lo que se podrían obtener, además, tarifas preferentes. Sin embargo, se establece unarelación de dependencia con la infraestructura del único ISP.

Diseño y Arquitectura de Redes Telemáticas 111

Page 122: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

Figura 4.16: Configuraciones redundantes para acceso a internet

La primera opción supone que el ISP cuenta con dos PoP relativamente cercanos entresí, lo cual no siempre es el caso, sobre todo en ciudades pequeñas. Las opciones 2 y 4 serecomiendan para redes geográficamente muy dispersas, por ejemplo redes continentaleso intercontinentales.

Con las opciones 3 y 4 se consigue, en principio, redundancia del proveedor de acceso,pero ésto debe tratar de verificarse con los ISPs pues con frecuencia no existe realmenteindependencia de circuitos. Los grandes ISPs suelen tener contratos entre ellos o con elproveedor de transporte dominante, para compartir circuitos, por lo que si éstos fallan, losdos ISPs dejarían de operar.

En todas las opciones, pero principalmente en las últimas dos, se deben definir eimplmentar políticas especiales de enrutamiento para evitar que la red de la organizaciónse vuelva una red de tránsito por el que los ISP intercambian tráfico entre ellos.

4.7. Problemas

4.1. ¿De qué manera la metodología de diseño jerárquico mejora el desempeño, ladisponibilidad y la escalabilidad de la red?

4.2. ¿En dónde (red de acceso, distribución, núcleo) colocaría:

(a) un firewall

(b) un switch que permita configurar VLANs

Diseño y Arquitectura de Redes Telemáticas 112

Page 123: Diseño y Arquitectura de Redes Telemáticas

4.7. PROBLEMAS

(c) un mecanismo de despacho de colas para ofrecer QoS?

4.3. ¿Qué tipo de interfaces (100BaseT en par trenzado, serial E1, fibra óptica altavelocidad, . . . ) esperaría encontrar en los enrutadores de acceso, de distribución yde núcleo? ¿Cuántas?

4.4. Discuta brevemente qué tipo de topología (malla total, malla parcial, hub andspoke) utilizaría para interconectar:

(a) un núcleo con 5 nodos;

(b) un núcleo con 20 nodos;

(c) una red de acceso para 5 nodos;

(d) una red de acceso para 20 nodos.

4.5. A partir de la siguiente matriz de costos, y considerando un valor deK = 3, ob-tenga los mejores candidatos para poner los concentradores de acuerdo al algoritmode Dysart-Georganas.

2 3 4 5 6 7 8 9 101 3 5 5 3 4 7 7.5 12 11.52 2 2 1 2.5 7 5 9 113 2 2 2 3.5 7 5 9 114 2 2 1 2.5 5 3 7 95 1 2 1 1.5 4.5 4 8 106 2.5 3.5 2.5 1.5 3 3.5 7.5 7.57 7 7 5 4.5 3 1 5 458 5 5 3 4 3.5 1 4 69 9 9 7 8 7.5 5 4 210 11 11 9 10 7.5 4.5 6 2

4.6. Considere la distribución de nodos en la figura y el tráfico introducido en ca-da nodo. Los valores entre nodos representan distancias en km. El tamaño de lospaquetes es de 6, 000 bits. Considerando que los enlaces entre ciudades son E0,

(a) Obtenga mediante el algoritmo de Kruskal la topología de árbol mínimo.

(b) Obtenga la topología de menor costo considerando que el retraso por se-gundo es de $1, 000.00. Suponga que el nodo inferior derecho es el concentra-dor y que el costo de los enlaces es de $40.00/km.

4 pps

4 pps 5 pps

20

30

8

5

25

15

Diseño y Arquitectura de Redes Telemáticas 113

Page 124: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

4.7. Se desea diseñar una red para interconectar las delegaciones del Distrito Fede-ral con las siguientes consideraciones:

Dado que las delegaciones Milpa Alta (MA), Xochimilco (XO) y Tláhuac(TL) están muy alejadas de las demás, éstas se conectarán entre sí en un anillodoble.La delegación XO servirá de conexión entre MA y TL con las demás dele-gaciones. Tendrá dos conexiones a la red de delegaciones (es decir, su gradototal será K=4).Las delegaciones Miguel Hidalgo (MH), Cuauhtémoc (CU), Benito Juárez(BJ), Álvaro Obregón (AO) y Coyoacán (CO) tendrán tres enlaces redundantes(K=3).Las demás delegaciones tendrán dos enlaces (K=2). Son Azcapotzalco (AZ),Cuajimalpa (CJ), Gustavo A. Madero (GM), Iztacalpo (IC), Iztapalapa (IP),Magdalena Contreras (MC), Tlalpan (TP) y Venustiano Carranza (VC).La tabla de distancias (equivalente al costo) se muestra a continuación, juntocon el identificador de cada delegación y el grado inicial de los dispositivosde interconexión.

Muestre el diagrama de la red enumerando los enlaces conforme los va definiendo.

Diseño y Arquitectura de Redes Telemáticas 114

Page 125: Diseño y Arquitectura de Redes Telemáticas

4.7. PROBLEMAS

Id AO AZ BJ CO CJ CU GM IZ IP MC MH MA TL TP VC X0 K4 AO 10.56 4.40 5.50 11.55 7.32 13.06 10.17 11.30 10.63 1.81 29.89 23.96 11.61 7.60 16.41 39 AZ 10.56 12.90 15.08 18.54 5.86 7.55 12.10 16.96 20.85 8.85 37.77 30.38 21.83 10.39 26.47 28 BJ 4.40 12.90 2.37 14.94 7.88 12.80 6.85 7.03 11.46 4.91 25.78 19.59 9.21 7.12 13.65 31 CO 5.50 15.08 2.37 14.43 10.20 15.11 8.41 7.44 9.74 6.64 24.38 18.79 6.89 9.22 11.77 313 CJ 11.55 18.54 14.94 14.43 18.06 23.70 21.55 21.79 8.49 12.79 36.30 32.45 15.85 19.55 22.93 22 CU 7.32 5.86 7.88 10.20 18.06 5.77 7.62 11.11 17.88 5.61 31.93 24.53 17.08 4.75 20.99 310 GM 13.06 7.55 12.80 15.11 23.70 5.77 9.28 13.38 23.52 11.36 33.89 25.73 21.82 6.52 24.55 211 IZ 10.17 12.10 6.85 8.41 21.55 7.62 9.28 4.10 18.13 9.50 24.82 17.04 13.96 3.08 15.43 215 IP 11.30 16.96 7.03 7.44 21.79 11.11 13.38 4.10 16.82 11.28 20.89 13.48 11.21 7.04 11.48 23 MC 10.63 20.85 11.46 9.74 8.49 17.88 23.52 18.13 16.82 12.43 28.11 25.15 7.97 18.52 14.89 214 MH 1.81 8.85 4.91 6.64 12.79 5.61 11.36 9.50 11.28 12.43 30.69 24.37 13.07 8.01 18.37 316 MP 29.89 37.77 25.78 24.38 36.30 31.93 33.89 24.82 20.89 28.11 30.69 8.75 20.44 27.87 13.37 25 TL 23.96 30.38 19.59 18.79 32.45 24.53 25.73 17.04 13.48 25.15 24.37 8.75 17.22 20.11 11.04 26 TP 11.61 21.83 9.21 6.89 15.85 17.08 21.82 13.96 11.21 7.97 13.07 20.44 17.22 15.60 7.08 27 VC 7.60 10.39 7.12 9.22 19.55 4.75 6.52 3.08 7.04 18.52 8.01 27.87 20.11 15.60 18.03 212 XO 16.41 26.47 13.65 11.77 22.93 20.99 24.55 15.43 11.48 14.89 18.37 13.37 11.04 7.08 18.03 2

4.8. Mediante el método de Stieglitz-Weiner-Kleitman, interconecte los nodos si-guientes con un nivel de redundancia = 2. Considere que no está permitida la cone-xión entre los nodos 1 y 5.

ENUMERE LOS ENLACES CONFORME LOS VAYA DEFINIENDO

4.9. Diseñe la topología de costo mínimo con el método de Esau-Williams para unared cuya matriz de costos es la siguiente.

2 3 4 5 6 71 1 4 3 2 7 92 2 6 9 3 53 4 7 1 34 9 6 25 3 36 77

Estime el costo inicial y final.

4.10. Para la siguiente matriz de costos, utilice el método de Kruskal para obtenerla topología óptima:

Diseño y Arquitectura de Redes Telemáticas 115

Page 126: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 4. DISEÑO LÓGICO

1 2 3 4 51 – 6 3 3 52 6 - 3 5 13 3 3 - 4 54 3 5 4 - 35 5 1 5 3 -

4.11. Diseñe la topología del núcleo de red que se muestra en la figura medianteel método de Stieglitz-Weiner-Kleitman. Se desea que la red pueda subsistir a dosfallos por lo menos. Los enlaces que se muestran en la figura ya están establecidosy no pueden eliminarse. Las líneas punteadas en la figura sirven únicamente comoreferencia.

8 12 3

5 10

1 9 7

6

4

2 11�����

@@@@@

�����

@@@@@

4.12. Explique brevemente para qué se utiliza la siguiente fórmula y qué signifcacada uno de sus términos.

v̄ =⌊ F

Σj=1Sj × j

N

⌋+ 1

4.13. La siguiente es una matriz de tráfico en paquetes por segundo en la hora picopara la red de la figura. Los enlaces deben dimensionarse con una capacidad tal quela utilización durante la hora pico sea de 80 %.

Diseño y Arquitectura de Redes Telemáticas 116

Page 127: Diseño y Arquitectura de Redes Telemáticas

4.7. PROBLEMAS

A B C DA 11, 000 900 750 10 500B 14, 000 10, 000 2, 000 1 300C 9 500 1 800 4 200 0D 18 700 550 0 3 150

C A D

B

,,,,,,,, l

lllllll

(a) Dimensione todos los enlaces.

(b) Considere que A − C y A − D deben repartirse equitativamente la cargade A−B si este enlace falla. ¿Con qué capacidad deben dimensionarse estosenlaces?

4.14. Un concentrador hacia el núcleo recibe 25 enlaces como se muestra en latabla. El núcleo está diseñado con una redundancia de K=3 y los enlaces (las tron-cales) no deben exceder 50 % de utilización. ¿De qué capacidad deben ser estosenlaces?

No. enlaces Capacidad Utilización5 E1 37 %10 1Mb/s 57 %10 E0 75 %

4.15. De acuerdo al método de diseño con bloques funcionales, dibuje un bloquebásico de red de acceso para una LAN.

4.16. Mencione algunas de las consideraciones principales a tomar en cuenta cuan-do se decide contratar accesos a internet a través de dos proveedores de serviciodistintos.

Diseño y Arquitectura de Redes Telemáticas 117

Page 128: Diseño y Arquitectura de Redes Telemáticas
Page 129: Diseño y Arquitectura de Redes Telemáticas

Capítulo 5

Administración de redes

La administración de redes es una parte fundamental de los sistemas integrados degestión de sistemas de información. Con el enorme crecimiento en la variedad y númerode equipos y redes como el ambiente mostrado en la figura 5.1, una administración centra-lizada resulta impensable. La integración de equipos heterogéneos impide la utilizaciónde sistemas propietarios de bajo nivel.

La administración de redes representa el conjunto de funciones que permiten una ade-cuada explotación, mantenimiento, seguridad y seguimiento en la operación de la red.

Figura 5.1: Red heterogénea

Para poder garantizar el acceso ubicuo a la información y servicios en las redes hetero-géneas tendrá que haber una inversión considerable en tecnologías de gestión y monitoreode redes y sistemas (NSM, network and systems management). Una mala estrategia deNSM es la razón típica por la que falla un esfuerzo de downsizing, así como por la que seperciben bajos incrementos en la productividad del personal no técnico.

En el viejo modelo de cómputo centralizado, los administradores debían preocuparseúnicamente por el equipo central y unas cuantas terminales tontas. En la actualidad, elmodelo está basado en estaciones de trabajo inteligentes, capaces de realizar muchas más

Page 130: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

tareas pero que al mismo tiempo necesitan más dedicación y tiempo para su instalación,configuración, evaluación y mantenimiento.

Estudios recientes (figura 5.2) sobre los costos incurridos en redes en Estados Unidos,muestran que el costo anual de administración de sistemas excede los costos de adquisi-ción tanto de hardware como de software.

Figura 5.2: Retos en la gestión de TI por su evolución

5.1. Evolución de administración de sistemas

La evolución de los sistemas administrativos comienza con la administración tradi-cional del Mainframe y sus equipos asociados. A este ambiente de administración se lellamaba de invernadero (Glass house). Durante más de treinta años, los responsables delos sistemas informáticos debían gestionar todos sus sistemas en el centro de cómputo.En grandes centros, esto implicaba decenas de herramientas distintas, todas ellas especia-lizadas en cada una de las plataformas disponibles.

Conforme fue evolucionando el ambiente de cómputo, lo fue haciendo su gestión,transitando hacia un modelo distribuido donde se debía considerar la administración de:

Minicomputadoras

Estaciones de trabajo

Computadoras personales departamentales

A estos sistemas de cómputo hoy deben agregarse equipos portátiles como laptops,tabletas y hasta teléfonos inteligentes.

Además de los equipos terminales, la gestión debe incluir, por supuesto, los equiposde interconexión, que es el tema central de este capítulo.

De acuerdo al marco de referencia OSI, los componentes básicos de administraciónde redes se conforman por cinco subsistemas:

Diseño y Arquitectura de Redes Telemáticas 120

Page 131: Diseño y Arquitectura de Redes Telemáticas

5.1. EVOLUCIÓN DE ADMINISTRACIÓN DE SISTEMAS

Gestión de fallas (Fault Management)

Gestión de configuración (Configuration Management)

Gestión de seguridad (Security Management)

Gestión de rendimiento (Performance Management)

Contabilidad de recursos (Accounting Management)

En el modelo OSI, estos subsistemas ofrecen un conjunto de servicios: Common Ma-nagement Information Services, CMIS, con ayuda del protocolo de nivel de aplicaciónCommon Management Information Protocol, CMIP.

5.1.1. Gestión de fallas

La gestión de fallas debe ser preferentemente proactiva, es decir, se debe tratar deidentificar tempranamente una condición potencial de falla antes de que ésta se mani-fieste. Se sigue un modelo de gestión activa en el que un mecanismo de sondeo solicitainformación a los dispositivos administrados.

Debe haber un compromiso entre la precisión de la información adquirida y la canti-dad de tráfico inyectado; también deben contemplarse canales alternos para recabar infor-mación de los dispositivos en caso de fallos en la red.

También debe definirse con claridad, como se mencionó al presentar el modelo deadministración de riesgos, que es importante definir qué fallas se desean gestionar y cuálesno. Debe considerarse que hay muchos tipos de fallos que ocurren raramente, pero sobretodo tienen un impacto bajo en el desempeño de la red, por lo que quizás no merece lapena incluirlas en el modelo (automatizado) de gestión de fallas.

En el proceso de localizar y corregir problemas en la red, los tres pasos básicos son:

Identificar (pasiva o activamente) un comportamiento anormal de la red.

Aislar el problema; minimizar su impacto en el resto de la red. Tratar de reprodu-cirlo para poder analizarlo.

Corregir el problema.

5.1.2. Gestión de configuración

La gestión de configuración tiene por objeto alinear la configuración de equipos a laspolíticas de operación definidas, simplificar su despliegue y minimizar errores durante es-te proceso. Para ello, es muy recomendable definir perfiles de usuarios con sus respectivospermisos para acceso a equipos y servicios de red.

Diseño y Arquitectura de Redes Telemáticas 121

Page 132: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

Las gestión de configuración debe tomar en cuenta tanto el nivel físico como el nivellógico de la red. En operación, este subsistema obtiene datos e información de la red y losutiliza para gestionar la configuración de los diferentes dispositivos. Para ello se debe:

Obtener información sobre la configuración actual de la red, incluyendo dispositi-vos instalados por el usuario (autodiscovery);

Utilizar dicha información y las herramientas (automatizadas) para modificar losdispositivos según se desee;

Almacenar información, mantener y actualizar el inventario y producir reportes. Es-te inventario debe incluir elementos como direcciones asignadas, hardware y soft-ware instalado, números de serie, localización física, capacidad, etcétera.

5.1.3. Gestión de seguridad

La gestión de seguridad no se limita a los mecanismos de seguridad (protocolos, me-canismos de encripción) sino a toda la política de seguridad que debe ser implementadaen la organización, como la administración de contraseñas, responsabilidades de los usua-rios, seguridad de acceso físico, entre muchos otros. En capítulos posteriores se tratará conmás detalle este tema.

La protección de información importante se logra mediante la limitación en el accesode los usuarios a hosts y dispositivos de red y mediante la notificación al administradorde red de intentos y violaciones de seguridad. Para realizar estos objetivos tenemos que:

Definir e identificar la información que será protegida.

Localizar los puntos de acceso a dicha información.

Asegurar dichos puntos de acceso mediante los mecanismos apropiados (encrip-ción, filtrado de paquetes, Identificación de hosts e Identificación de usuarios).

Incluir seguridad física (control de acceso) de los dispositivos.

5.1.4. Gestión de rendimiento

El objetivo de la gestión de rendimiento es el garantizar que la red está dentro de losparámetros de operación definidos en la etapa de diseño, mediante el monitoreo de los dis-positivos de red y sus enlaces asociados para determinar su utilización, niveles de error,etcétera. El monitoreo continuo permite una gestión proactiva de la red y ayuda a anti-cipar las extensiones y cambios necesarios cuando la infraestructura de comunicacionesempieza a rebasar sus condiciones óptimas de operación.

La gestión de rendimiento puede ser extremo a extremo y por componente. Debenidentificarse las métricas a utilizar para evaluar el rendimiento. Para lograr los objetivosde la gestión de rendimiento es recomendable:

Diseño y Arquitectura de Redes Telemáticas 122

Page 133: Diseño y Arquitectura de Redes Telemáticas

5.2. PROTOCOLOS DE ADMINISTRACIÓN

Reunir información de la utilización actual de dispositivos y enlaces, como tiempode respuesta, ocupación media de las colas, disponibilidad (MTBF), etcétera.

Analizar la información relevante par discernir si hay altos niveles de utilización.

Fijar umbrales de utilización.

Valerse de herramientas de simulación para determinar cómo la red puede ser alte-rada para maximizar su rendimiento.

5.1.5. Contabilidad de recursos

La gestión contable o auditoría de recursos almacena y procesa datos referentes alconsumo de los recursos de la red. Esta información puede ser utilizada para fines detarificación y también como apoyo para planear la capacidad y/o detectar fallas de la red.En esencia, la gestión contable implica:

Medir la utilización de los recursos de la red para determinar su correcta distribu-ción.

Definir cuotas de uso utilizando métricas adecuadas.

Determinar y reportar costos y utilización, para cobrar a los usuarios por el servicio.

5.2. Protocolos de administración

Existe un conjunto amplio de protocolos y herramientas propietarias para la gestión deredes y sistemas informáticos, pero la admistración de redes se concentra en dos grandescategorías: el enfoque de administración de OSI y el de IETF.

5.2.1. Modelo de administración OSI

En el modelo de administración OSI cada capa cuenta con una .entidad de administra-ción de capa"(LME, layer management entity) que se comunica con la .entidad de aplica-ción de administración del sistema"(SMAE, system management application entity). LasSMAE se comunican entre sí a través de CMIP como se muestra en la figura 5.3.

Las primitivas del modelo definen los servicios ofrecidos (CMIS):

Set (manipular información de administración)

Action (ejecutar un comando, p.e., reinicio)

Get (leer información de administración)

Diseño y Arquitectura de Redes Telemáticas 123

Page 134: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

Figura 5.3: Modelo de gestión OSI

Create (crear una nueva instancia de un objeto)

Delete (eliminar una instancia de un objeto)

Event-report (reportar eventos anormales)

CMIS está basado en un modelo orientado a conexión. Todos los servicios se ofre-cen con confirmación, aunque Set, Action e Event-report también pueden ofrecerse sinconfirmación.

Observe que en este modelo, para que pueda haber intercambio de información, todala pila de protocolos debe estar funcionando.

5.2.2. Modelo de gestión IETF

A los inicios del desarrollo de Internet, se implementó el protocolo ICMP (InternetControl Message Protocol) para depuración, control y monitoreo de errores del protocoloIP. Una de sus aplicaciones más conocidas es la herramienta PING que permite verificarsi un dispositivo determinado es .alcanzable".

Claramente, este tipo de mecanismos es insuficiente para la administración de redescada vez más complejas. A mediados de los años 80 se reconoció la necesidad de incor-porar un mecanismo de administración de red. Se consideraba que las propuestas de OSIpara gestión debían ser incorporadas a Internet, pero OSI avanzaba muy lentamente, porlo que se optó en 1987 por seguir dos estrategias paralelas:

A corto plazo se desarrollaría un protocolo sencillo basado en SGMP (Simple Ga-teway Monitoring Protocol), un protocolo utilizado para depurar la operación deenruteadores. Este protocolo es SNMP (Simple Network Monitoring Protocol). La

Diseño y Arquitectura de Redes Telemáticas 124

Page 135: Diseño y Arquitectura de Redes Telemáticas

5.2. PROTOCOLOS DE ADMINISTRACIÓN

idea de base es: el impacto de añadir administración de red debe tener un efectomínimo en los nodos administrados

A largo plazo se debía soportar CMIP sobre TCP/IP: CMOT

Como se consideraba que las dos estrategias eventualmente deberían converger y, dehecho, se esperaba que la dominante fuera CMOT, se decidió definir un marco de referen-cia común inspirado en las ideas y las mejores prácticas de OSI.

El marco de referencia común consistió en la definición de una Estructura de Infor-mación Común (SMI, Structure of Management Information) y un conjunto de elementosde administración: la base de información de administración (MIB, Management Infor-mation Base). En otras palabras, el modelo de administración en IETF se divide en dospartes:

El formato de los mensajes (SMI) y el protocolo de transferencia entre agentes yadministrador: SNMP

La información que se administra: MIB

En general, los dispositivos tienen agentes encargados de colectar la información queles corresponde (las variables MIB) y el administrador contacta a los agentes para re-cabar esta información. Ver figura 5.4. Siguiendo la idea de no sobrecargar los nodos,los agentes son entidades simplificadas y la inteligencia es desplazada a la consola deadministración.

Figura 5.4: Modelo de gestión IETF

5.2.3. Simple Network Management Protocol

Especifica cómo debe ser la comunicación entre la estación de administración y losagentes para intercambiar información sobre las variables MIB en cuestión. En su primeraversión (SNMPv1) se definen únicamente cinco comandos:

Diseño y Arquitectura de Redes Telemáticas 125

Page 136: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

Get-request La consola solicita el valor de una variable

Get-next-request Solicita el valor de la siguiente variable. Se utiliza para recorrer tablas

Get-response El agente devuelve el valor solicitado

Set-request La consola establece el valor de una variable

Trap El agente reporta alguna anormalidad

La primera versión trabaja sobre UDP; en las últimas versiones, el protocolo de trans-porte puede ser TCP o UDP. Los comandos get, get-next y set esperan contactar al agenteen el puerto 161; el comando trap espera contactar al administrador en el puerto 162.

Las anormalidades reportadas con el comando trap están claramente definidas enSNMP aunque pueden extenderse. Como ejemplos de las anomalías reportadas tenemos:

Reinicio del sistema.

Enlace caído / restablecido.

Autentificación fallida.

Pérdida de vecino EGP.

Para los administradores de redes, SNMP se mantiene oculto detrás de paquetes desoftware conocidos como consolas de administración. La consola manda comandos y re-cibe respuestas de los agentes que se encuentran en los dispositivos administrados. Comose muestra en la figura 5.5, los agentes se encargan de recabar información sobre objetosdeterminados, los cuales son un subconjunto de la Base MIB.

Figura 5.5: Elementos de SNMP

Para que un administrador pueda interactuar con un agente, deben pertenecer a lamisma comunidad. Este concepto permite que en redes con muchos dispositivos la cargade la gestión se pueda distribuir entre varios administradores. En la figura 5.6 se apreciandos comunidades, public y public2.

En su empeño por mantener los agentes simples, SNMPv1 ignora el problema deseguridad de acceso. El identificador de comunidad es un campo en el paquete SNMPque viaja sin encriptar por la red.

Diseño y Arquitectura de Redes Telemáticas 126

Page 137: Diseño y Arquitectura de Redes Telemáticas

5.2. PROTOCOLOS DE ADMINISTRACIÓN

Figura 5.6: Comunidades SNMP

5.2.4. Base de datos de información de administración (MIB)

Se trata de una estructura jerárquica en la que se definen los identificadores de losobjetos (llamados las variables MIB) que pueden administrados a través de SNMP. Lasvariables MIB están organizadas en una estructura arborescente basada en el árbol deidentificadores de objetos (OID, Object Identifier definido en conjunto por OSI y por laITU. En la figura 5.7 se muestran las diez categorías de variables definidas en el RFC1213, que corresponden a la segunda versión de variables, las variables MIB-II, definidacuando se separan, en 1989, los grupos CMOT y SNMP.

Figura 5.7: Variables MIB-II en el árbol de identificadores de objetos

Un objeto o variable MIB-II tiene un identificador único recorriendo el árbol desde laraíz hasta la hoja que lo representa. El primer nivel del árbol tiene tres ramas: los objetosdefinidos por ISO (1), los definidos por ITU -anteriormente CCITT- (2) y los definidosconjuntamente por ISO e ITU. Abajo de ISO encontramos la rama que corresponde a lasorganizaciones (org, 3) y dejado de ésta, hay una rama para el Departamento de Defensade Estados Unidos (dod, 6).

Así se sigue recorriendo el árbol hasta llegar al objeto deseado. Por ejemplo, el identi-ficador 1.3.6.1.2.1.1.1 corresponde a la variable iso.org.dod.internet.mgmt.MIB-II.system.sysDescr.

Diseño y Arquitectura de Redes Telemáticas 127

Page 138: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

Una instancia de esa variable, es decir, el valor actual de la variable, es gestionado por elagente del dispositivo y se puede acceder a él agregando un 0 al OID de la variable, eneste caso, 1.3.6.1.2.1.1.1.0.

De manera similar, el OID 1.3.6.1.2.1.4.3.0 hace referencia a la instancia de la varia-ble IpInReceives bajo la rama IP, que lleva el conteo de datagramas IP recibidos por eldispositivo.

Los valores para la mayor parte de las características listadas pueden almacenarse enun solo entero. Sin embargo, MIB también define estructuras más complejas. Por ejemplo,la variable IpRoutingTable se refiere a la tabla de ruteo del ruteador.

Dado que la administración de la red involucra muchos equipos heterogéneos, los res-ponsables del protocolo establecieron normas muy específicas sobre cómo definir, identi-ficar y representar las variables. El conjunto de estas normas es lo que se conoce como laestructura de la información de administración (SMI, Structure of Management Informa-tion).

SMI indica que los objetos deben ser identificados en el árbol OID y deben ser de-finidos utilizando un subconjunto de la notación ASN.1 (Abstract Syntax Notation v1).ASN.1 es un metalengauje que permite representar de manera universal una información(tipos básicos y estructuras de datos complejas) y establece la forma en que debe ser co-dificada esta información para el intecambio de datos, es decir, la sintaxis de los objetos.

Para SNMP, se eligió BER (Basic Encoding Rules) como el formato de codificación.Como se muestra en la figura 5.8, la codificación BER tiene tres campos: El identificadordel tipo de objeto, la longitud del objeto y su valor.

Figura 5.8: Reglas de codificación BER

Como se muestra en la figura 5.8, los primeros dos bits indican si el objeto es un tipo dedatos üniversal", es decir, definido en ASN.1, si depende de la aplicación, si está definidoen un contexto determinado (por ejemplo, en el contexto de la definición de SNMP) o sies un objeto definido por el usuario. El tercer bit indica si el objeto es un tipo básico, comoun entero, o uno complejo, como una estructura de datos. Los cinco bits restantes de laetiqueta indican de qué objeto se trata dentro del dominio definido (universal, aplicación,etc.).

Si la longitud del objeto es menor a 127 bytes, ésta ocupa un solo campo (el segundoocteto de la codificación); si es mayor, el bit más significativo es "1 2los demás bits indicanel número de octetos subsecuentes que representan la longitud del objeto.

En la tabla 5.1 se muestran algunos de los tipos de datos universales definidos enASN.1 y se resaltan en negritas aquellos utilizados en la definición de SNMP, mientras

Diseño y Arquitectura de Redes Telemáticas 128

Page 139: Diseño y Arquitectura de Redes Telemáticas

5.2. PROTOCOLOS DE ADMINISTRACIÓN

que en la tabla 5.2 se muestran los objetos definidos en el contexto de SNMPv1 y quecorresponden a los PDU del protocolo.

Clase Tipo Descripción1 BOOLEAN Valores cierto o falso2 INTEGER Números enteros positivos o negativos3 BIT STRING Serie de bits sin representación específica4 OCTET STRING Cadena de caracteres5 NULL Entrada sin valor6 OBJECT IDENTIFIER Identificador de un objeto en el árbol OID7 OBJECT DESCRIPTOR Cadena que describe el objeto8 EXTERNAL Tipo definido en otro módulo9 REAL Número en punto flotante

10 ENUMERATED Lista de enteros16 SEQUENCE OF Conjunto de elementos17 SET, SET OF Lista no ordenada de elementos

Tabla 5.1: Ejemplo de tipos de datos universales en ASN.1

Clase Tipo de Dato0 GetRequest1 GetNextRequest2 GetResponse3 SetRequest4 Trap

Tabla 5.2: Tipos de datos ASN.1 en el contexto de SNMPv1

Formato de mensajes SNMP (v1)

En la definición SMI el formato de los mensajes SNMPv1 tiene la siguiente estructura:

Reques t ID = INTEGER ;E r r o r S t a t u s = INTEGER { n o E r r o r ( 0 ) , t o oBi g ( 1 ) , noSuchName ( 2 ) ,badValue ( 3 ) , r eadOnly ( 4 ) , g e n E r r o r ( 5 ) } ;E r r o I n d e x = INTEGER :va rB ind = SEQUENCE {name ObjName , s y n t a x ObjSyntax }

El protocolo está definido en el RFC 1157. Una sección de la definición se muestra acontinuación:

Diseño y Arquitectura de Redes Telemáticas 129

Page 140: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

RFC 1157−SNMP DEFINITIONS : : = BEGINIMPORTS ObjectName , O b j ec t Sy n t ax , . . .FROM RFC1155−SMI

Message : : = SEQUENCE {v e r s i o n INTEGER {

VERSION−1(0) } ,community OCTET STRING ,

d a t a ANY}PDUs : : = CHOICE {

ge t−r e q u e s t GetReques t−PDU,ge t−next−r e q u e s t GetNextReques t−PDU,ge t−r e s p o n s e GetResponse−PDU,s e t−r e q u e s t Se tReques t−PDU,t r a p Trap−PDU

}END

GetReques t−PDU : : = [ 0 ] IMPLICIT SEQUENCE {r e q u e s t−i d RequestID ,e r r o r−s t a t u s E r r o r S t a t u s ,e r r o r−i n d e x E r r o r I n d e x ,v a r i a b l e−b i n d i n g s V a r B i n d L i s t

}

Trap−PDU : : = [ 4 ] IMPLICIT SEQUENCE {e n t e r p r i s e OBJECT IDENTIFIER ,agen t−add r NetworkAddress ,g e n e r i c−t r a p INTEGER {

c o l d S t a r t ( 0 ) , wa rmSta r t ( 1 ) ,. . . } ,

s p e c i f i c −t r a p INTEGER ,t ime−s tamp TimeTicks ,v a r i a b l e−b i n d i n g s V a r B i n d L i s t

}

De esta manera, un mensaje SNMP versión 1 está formado por una secuencia concuatro campos: versión (tiene el valor 1), comunidad y cualquiera de cinco opciones parael PDU. El formato de los PDU para GetRequest (0), GetNextRequest (1), SetRequest (2)y GetResponse (3), es el mismo; lo único que cambia es el identificador de tipo de PDUcon los valores indicados en paréntesis.

En la figura 5.9 se muestra codificado un mensaje GetRequest de la variable sysDescr.El primer octeto es 0x30 hexadecimal (0011 0000 binario). Los dos primeros bits indicanque es un tipo de dato universal, el tercero que es un tipo complejo y los últimos cinco(con valor 10000 binario, es decir, 16) nos dice que se trata de un SEQUENCE segúnlo indica la tabla 5.1. Esto es consistente con el formato del mensaje definido en el RFC1157.

Diseño y Arquitectura de Redes Telemáticas 130

Page 141: Diseño y Arquitectura de Redes Telemáticas

5.2. PROTOCOLOS DE ADMINISTRACIÓN

Como el mensaje está codificado con reglas BER, el segundo octeto, 0x29 (41 deci-mal) muestra la longitud de esa estructura y los campos subsecuentes indican su valor.

Figura 5.9: Mensaje SNMP, PDU GetRequest con codificación BER

Como se trata de una solicitud, los campos errorStatus y errorIndex tienen un valorde cero. Para el campo OID hay un tratamiento especial: dado que el primer dígito sólopuede ser 0,1 ó 2 y el segundo es menor a 39, estos dos se combinan en un solo octetosiguiendo la fórmula 40 ∗ A+B, donde A es el primer dígito y B es el segundo.

SNMPv2 y v3

SNMPv1 (RFC 1157) no toma en cuenta la seguridad. Además, el acceso a las va-riables mediante los PDU GetRequest y GetNextRequest es muy ineficiente si se desearecabar mucha información.

La segunda versión introduce mejoras en las áreas de:

Rendimiento, Se agregan los PDU Get-bulk, Inform y se definen contadores con untamaño mayor a 64 bits, entre otras).

Seguridad. Desgraciadamente, los mecanismos para implementar seguridad en lasegunda versión podían ser incompatibles entre sí, por lo que al final del día se tuvoque abandonar.

Comunicaciones administrador-administrador.

La tercera versión, SNMPv3 (RFC 2570-2576), tiene la categoría de Proposed Stan-dard. es una profunda revisión del protocolo en la que se retienen las mejores propuestasde la versión 2 y se aclaran las confusiones para asegurar los mensajes mediante algo-ritmos de cifrado y autenticación. También se da flexibilidad para que el protocolo detransporte pueda ser UDP o TCP.

Diseño y Arquitectura de Redes Telemáticas 131

Page 142: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

5.3. RMON

Si cada dispositivo que es administrado con SNMP está conectado a una red, entoncespuede contribuir al monitoreo activo de sus segmentos de red local como si se tratara deun analizador de protocolos. Eso es lo que se busca con RMON (Remote monitoring), unaextensión a las variables MIB definida en el RFC 1757.

Como se muestra en la figura 5.10, las funciones de monitoreo se dividen en diezgrupos y permiten el monitoreo de topologías Ethernet y Token Ring. El agente se instalaen sondas (probes).

La segunda versión, RMON2, agrega objetos para el monitoreo de tráfico de red porencima de la capa de MAC.

Figura 5.10: Árbol OID para variables RMON

5.4. Administración de sistemas con SNMP

Como se comentó al inicio de este capítulo, SNMP puede ser utilizado para gestionardispositivos y equipos terminales que estén conectados a la red aunque no formen partede su operación. Para ello, sólo es necesario que se definan las variables MIB correspon-dientes en el árbol OID, típicamente debajo de la rama para enterprises. Por supuesto, los

Diseño y Arquitectura de Redes Telemáticas 132

Page 143: Diseño y Arquitectura de Redes Telemáticas

5.5. PROBLEMAS

dispositivos deben tener los agentes dedicados a monitorear y actualizar los contadoresrelacionados con esas variables.

Por ejemplo, con las extensiones MIB privadas, la estación de administración puedeconsultar al agente SNMP de una impresora y detectar el nivel de tóner o de hojas enla bandeja de impresión. De la misma forma, podría consultar un agente en un servidorpara conocer la ocupación media de memoria principal, el espacio disponible en disco, elnúmero de procesos activos, entre muchos otros parámetros.

5.5. Problemas

5.1. De acuerdo al modelo de OSI, la gestión de la red se divide en cinco compo-nentes. Descríbalos brevemente.

5.2. Seleccione las respuestas correctas

SNMP define que se enviarán del administrador al agente y viceversa(A) el formato de los paquetes(B) la codificación de los paquetes(C) el número de paquetes(D) ninguno de los anteriores

Un agente es una computadora en la que se ejecuta el proceso deSNMP (A) cliente(B) servidor(C) cliente y servidor(D) ninguno de los anteriores

SMI enfatiza tres atributos para manipular un objeto:(A) nombre; tipo de dato; tamaño(B) nombre; tamaño; método de codificación(C) nombre; tipo de dato; método de codificación(D) ninguno de los anteriores

El OID de todos los objetos administrados por SNMP comienza por:(A) iso.org.dod.internet.management.mib.(B) iso.org.dod.internet.management.mib-II.(C) iso-itu.std.dod.internet.management.mib-II.(D) ninguna de las anteriores

Para definir sus tipos de datos, SMI utiliza y extiende las definiciones de ob-jetos establecidas en(A) ASN.1(B) BER(C) SNMP(D) ninguna de las anteriores

Diseño y Arquitectura de Redes Telemáticas 133

Page 144: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 5. ADMINISTRACIÓN

SMI se basa en el estándar para codificar la información que serátransmitida por la red(A) MIB(B) ASN.1(C) BER(D) ninguna de las anteriores

El PDU GetReques se envía del para obtener el valor de una variableo conjunto de variables(A) cliente al servidor(B) servidor al cliente(C) servidor a la red(D) ninguna de las anteriores

5.3. ¿Qué valor tiene el entero codificado en BER 02 01 08?

5.4. Describa brevemente las operaciones Get, Get Next, Trap e Inform de SNMP

5.5. Mencione los principales cambios propuestos en SNMPv3 respecto de SNMPv1

5.6. Codifique el siguiente segmento utilizando reglas BER. Suponga que los iden-tificadores de los tipos de datos son: (1) Boolean, (2) integer, (9) real, (16) sequence,(28) character string. Suponga también que los enteros son de longitud variable yque los números de punto flotante son siempre de 8 bytes.

int x = 0xFE3A04;float y[2] = {1.23, 4.0};struct { char nombre = ‘‘Luis Felipe’’;

int edad = 25;boolean casado = 0; }status;

char seccion = ’K’;

Diseño y Arquitectura de Redes Telemáticas 134

Page 145: Diseño y Arquitectura de Redes Telemáticas

Capítulo 6

Tecnologías de acceso

En este capítulo se presentan algunas de las tecnologías más populares para el des-pliegue de redes, tanto para la red de acceso como para el núcleo.

Por su relevancia en la sociedad contemporánea, antes de presentar las tecnologíasde acceso, iniciamos esta parte con algunas estadísticas sobre la penetración de internet.Esta información nos será de mucha utilidad al analizar la factibilidad de garantizar lacobertura de Internet a toda la población 1.

6.1. Cobertura de Internet

Internet se ha consolidado como una herramienta muy poderosa que ha afectado prác-ticamente todas las esferas en las que nos desarrollamos como sociedad. Desde su crea-ción, la cobertura de Internet ha crecido muy rápidamente. Como se observa en la figu-ra 6.1, mientras en 1995 el número de usuarios llegaba a 16 millones, lo que representabaun 0.2 % de la población mundial total, en diciembre de 2018 el número de usuarios al-canzó los 4,313 millones, aproximadamente 56.5 % de la población.

En marzo de 2019 esta cifra alcanzó un total de 4,346 millones los cuales se distribuíangeográficamente como se muestra en la figura 6.2a. Sin embargo, al analizar la tasa depenetración por región, se observa una enorme desigualdad, la cual puede estar ligada afactores socioeconómicos en términos de acceso a servicios de Internet, pues mientrasque en Norteamérica y Europa la penetración rebasa el 85 %, tanto Asia (51.7 %) comoÁfrica (35.9 %) se encuentran por debajo del promedio global de 56.3 %.

6.1.1. Red de acceso

Una red de acceso es la parte de una red de comunicaciones que conecta a los sus-criptores con su proveedor de servicios inmediato. Un ejemplo de red de acceso es el par

1Agradecemos la colaboración de Rodrigo Calderón Serafín y Diego Gutiérrez Romero para actualizareste material.

Page 146: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Figura 6.1: Usuarios de Internet por año

(a) Número de usuarios en el eje y porcentaje enla barra.

(b) Tasa de penetración

Figura 6.2: Usuarios de Internet y tasa de penetración por región. Datos a marzo de 2019

trenzado en el bucle local del operador telefónico, también llamado última milla, que serefiere a la porción de la red que alcanza físicamente las premisas del usuario final.

La infraestructura de las redes de acceso puede llegar a representar entre el 70 % y80 % de los recursos físicos para los incumbentes. Las redes de acceso representan unmercado muy competido y con muchos retos para los proveedores, sin embargo, tambiénes un mercado con grandes tendencias de crecimiento. En la década anterior representa-ba del 16 % al 20 % de los ingresos globales de las empresas de telecomunicaciones yprácticamente todos los operadores tradicionales.

Se observan dos tendencias en la oferta de los proveedores de acceso a Internet:

Las Redes de Nueva Generación (NGN, Next Generation Network), que ofrecenuna amplia gama de servicios de valor agregado en la última milla (independien-temente de la tecnología de acceso). Su modelo de negocios está basado en losservicios ofrecidos.

Diseño y Arquitectura de Redes Telemáticas 136

Page 147: Diseño y Arquitectura de Redes Telemáticas

6.1. COBERTURA DE INTERNET

La provisión de acceso, que ofrece infraestructura con muy alta capacidad y unsuministro de bajo costo (dumb pipes). Los servicios ofrecidos son de bajo valoragregado, por lo cual su modelo de negocio está basado en la administración de lainfraestructura.

Actualmente, la mayoría de los operadores busca migrar hacia las NGN debido a losincentivos que ofrecen, entre los que se encuentran maximizar los ingresos a través de laoferta de nuevos servicios de Internet (correo electrónico, compartir archivos, mensajeríainstantánea, comunicaciones unificadas, navegación, Web 2.0, etc.) y la conformación depaquetes de triple y cuádruple play (voz, banda ancha y televisión, y acceso móvil).

En la figura 6.3 se observa cómo en seis años cambió drásticamente la conformacióndel tipo de tráfico cursado pro los operadores móviles. El tráfico de voz se ha mantenidorelativamente estable, pero el de datos ha crecido más que exponencialmente. La figura 6.4muestra cómo durante el mismo periodo el crecimiento en ingresos se ha mantenido máso menos estable (0.3 % de aumento). El incremento mayor en ingresos viene de la ventade equipos móviles.

Figura 6.3: Tráfico por tipo Figura 6.4: Ingresos

La tendencia hacia mayores servicios a través de Internet explica el crecimiento ex-ponencial en el tráfico cursado. Tan sólo de 2010 a 2017, el volumen de datos se ha in-crementado 40 veces. Esto hace necesario un despliegue de infraestructura, creando así elcírculo virtuoso de la economía digital (figura 6.5) en el que una mayor oferta de serviciosy contenidos produce un aumento en la demanda de los mismos, lo cual hace necesarioun nuevo despliegue de redes. Redes más poderas permiten la creación de contenido yservicios de más calidad y con mayores demandas de capacidad... y así sucesivamente.

Los mayores obstáculos que enfrenta este círculo, es la demanda excesiva por el cre-cimiento de flujos de video, como lo muestran los datos de Cisco VNI presentados en lafigura 6.6. En el 2017, el 59 % del tráfico de datos móviles era de video y se estima quepara 2022 será del 79 %.

Diseño y Arquitectura de Redes Telemáticas 137

Page 148: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Figura 6.5: Círculo virtuoso de la econo-mía digital

Figura 6.6: Tráfico de datos móviles actualy estimado por tipo

6.1.2. Contexto de Internet y servicios de Banda Ancha en México

En los últimos años la cantidad de usuarios de Internet en México ha crecido conside-rablemente, alcanzando 71.3 millones en el 2017, lo que representa más del doble de losusuarios en 2010.

Figura 6.7: Usuarios de Internet en México

Sin embargo, recordemos que es necesario considerar el aumento en la oferta de esteservicio no sólo en términos de cantidad de usuarios, sino la tasa a la que se da estapenetración con relación a otras economías, y el porcentaje de penetración dentro de lasdistintas regiones del país2.

Comparando la penetración de Internet en México con otras economías, hacia el año2018 la figura 6.8 muestra que en 2018, la cobertura en México se encuentra por encimadel promedio en Latinoamérica con un 65 % de penetración, aunque un poco lejos deArgentina, Chile y Costa Rica.

2En este curso no ahondaremos en las tasas de penetración y las inequidades de cobertura de Internet enMéxico, pero debemos tenerlo presente.

Diseño y Arquitectura de Redes Telemáticas 138

Page 149: Diseño y Arquitectura de Redes Telemáticas

6.1. COBERTURA DE INTERNET

Figura 6.8: Penetración de Internet en América Latina (2018)

Si ahora vemos la situación de México con respecto a la OCDE, el panorama cambiadrásticamente pues el país se encuentra en las últimas posiciones en servicios de banda an-cha tanto fija (penúltimo lugar, figura 6.9) como móvil (ante penúltimo lugar, figura 6.10).Cabe destacar que en el servicio móvil las suscripciones ofrecidas son prácticamente ensu totalidad de voz y datos, en vez de ofrecer también suscripciones de sólo datos, comoprácticmaente todos los países de la OCDE.

Figura 6.9: Suscripciones de banda ancha fija (OCDE)

Figura 6.10: Suscripciones de banda ancha móvil (OCDE)

Diseño y Arquitectura de Redes Telemáticas 139

Page 150: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

6.1.3. Banda Ancha

Hemos estado hablando de banda ancha. Se trata de un término particularmente elu-sivo al tratar de definirla. La banda ancha puede verse como un conjunto de tecnologíasde red avanzadas o como el motor de una radical y gran transformación que revitaliza laentrega de los servicios existentes y da pie a la aparición de nuevos e innovadores servi-cios. La banda ancha se ha convertido en una infraestructura fundamental que determinala competitividad nacional de los países en la economía digital mundial.

En términos técnicos, la banda ancha ha tratado de definirse en función de las ve-locidades de transmisión mínimas, del tipo de tecnología (por ejemplo, IMT-Avanzadasmóviles o las llamadas tecnologías 4G), y de una serie de conceptos funcionales entre losque se encuentran conexión permanente y alta capacidad.

El debate para tratar de definirla no se ha detenido, y a manera de conciliación, sueledefinirse de manera informal e imprecisa, a la banda ancha como las tecnologías quepermiten la entrega fiable con con calidad de servicios convergentes de voz, datos y video.

La banda ancha ha demostrado ser un elemento esencial para el desarrollo económi-co, a tal punto que en 2010 Finlandia la declaró como un derecho ciudadano, al mismonivel que la alimentación, la salud y la educación, pues promueve la creación de nuevosservicios digitales, mayor eficiencia y productividad, estimula la competitividad, habilitaventajas de la globalización y promueve el acceso a redes de innovación. En México, sibien no se especifica con servicios de banda ancha, el acceso a Internet se convirtió en underecho ciudadano plasmado en la Constitución, con la Reforma en Telecomunicacionesde 2013.

La figura 6.11 muesra el nivel de penetración de banda ancha fija en los países de laOCDE en 2018, así como su ingreso per cápita en dólares PPP3. Hay una clara relaciónentre penetración banda ancha y nivel de riqueza, pero es difícil demostrar cuál es ladirección de la causalidad.

Figura 6.11: Penetración de banda ancha vs GDP (OCDE)

3El costo del dólar llevado a Paridad de Poder Adquisitivo (Parity Purchasing Power) para eliminar lasdiferencias entre el valor de las distintas economías).

Diseño y Arquitectura de Redes Telemáticas 140

Page 151: Diseño y Arquitectura de Redes Telemáticas

6.2. TECNOLOGÍAS DE ACCESO

Prácticamente todos los países desarrollados y en vías de desarrollo disponen de bandaancha. Hoy en día la principal preocupación es evitar la creación de brechas digitales entérminos de velocidad o calidad de acceso. Grupos multipartitas como la Comisión de laBanda Ancha para el Desarrollo Digital de las Naciones Unidas están fomentando quetodos los países en sus planes de desarrollo den prioridad al desarrollo de redes fijas ymóviles de alta velocidad a fin de cimentar sus previsiones de crecimiento económico alargo plazo y de competitividad en la era de la información.

Parece que en México todavía hay mucho por hacer en banda ancha fija pues tenemosun gran rezago en términos de velocidades y de suscripciones, como lo muestra la figu-ra 6.12. Podemos ver que el país apenas llega a un nivel de alrededor de 15 suscripcionespor cada 100 habitantes, y de éstas, la gran mayoría son de una velocidad de entre 10y 25 Mbps. Esto se encuentra muy lejos de objetivos como los fijados en Europa, queestablecen una penetración del 100 % al menos a 30 Mbps y del 50 % al menos a 100Mbps y hacia 2018 se encuentran cerca de ser alcanzados, según el reporte DESI (DigitalEconomy and Society Index) de la Comisión Europea de 2018.

Figura 6.12: Banda ancha fija. Penetración y velocidades de acceso (OCDE)

Con relación a los costos a usuarios finales, México presenta un rango de precios muygrande en comparación con otros países de la OCDE, con costos que van de aproxima-damente 30 dólares PPP para usuarios de bajo nivel (20 GB/mes, 0.250 Mbps) a los 65dólares PPP para usuarios de alto nivel (200 GB/mes, 25 Mbps). Este comportamiento sedebe principalmente a que si bien los precios a usuarios de bajo nivel se encuentran enel promedio de la OCDE, cuando vemos los precios ofertados a usuarios de alto nivel,México tiene los niveles más elevados como se observa en la figura 6.13. Aún con preciosajustados PPP, el acceso a banda ancha fija sigue siendo muy costoso para los deciles másbajos de la población nacional; justamente los grupos de población que se encuentranfuera de los servicios de Internet.

6.2. Tecnologías de acceso

Las expectativas de tráfico para los próximos años alcanzan niveles difíciles de asi-milar. Se estima que para 2022, el tráfico IP anual será de 4.8 zettabytes4, lo cual, para

41 zettabyte = 1021 bytes

Diseño y Arquitectura de Redes Telemáticas 141

Page 152: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

(a) Costos a usuarios de bajo nivel (b) Costos a usuarios de alto nivel

(c) Rangos de costos (USD, PPP)

Figura 6.13: Comparativo de costos (USD, PPP) en países de la OCDE a junio de 2017

dimensionar la magnitud, es igual a 11 veces el tráfico generado en 2012. 82 % de esetráfico será de aplicaciones de video y 71 % será por medio de tecnologías inalámbricas.

Para cumplir con estas expectativas, las tecnologías de acceso deben estar en constanteevolución de manera que la provisión de contenidos y servicios innovadores.

Las tecnologías de acceso pueden clasificarse en dos categorías:

Tecnologías por línea, como lo son:

• xDSL

• Cable Módem

• PLC

Diseño y Arquitectura de Redes Telemáticas 142

Page 153: Diseño y Arquitectura de Redes Telemáticas

6.2. TECNOLOGÍAS DE ACCESO

• Fibra + cable

Tecnologías inalámbricas, tales como:

• WiFi

• WiMax

• Celular

• Satélite, HAP

• Radio cognitivo

6.2.1. Tecnologías de acceso cableadas

xDSL

xDSL (Digital Subscriber Line, Línea de Abonado Digital) es una familia de tecno-logías que proporcionan acceso a Internet mediante la transmisión de datos a través delpar trenzado de hilos de cobre convencionales de la red telefónica convencional. Emplealos rangos de frecuencia que no son utilizados para el transporte de voz, maximizando asíel ancho de banda de la red de acceso (llamada la red de última milla) de los operadorestelefónicos.

En el equipo que se coloca en las instalaciones del usuario5 hay un filtro (splitter)el canal de frecuencias bajas, dedicado a los servicios de voz, del resto de frecuencias,dedicadas a la transferencia de datos.

De forma similar, en la central telefónica las tarjetas DSLAM (Digital SubscriberLine Access Multiplexer) separan las frecuencias bajas (que dirigen a la red telefónica)de las altas, donde viaja el tráfico que debe ser dirigido a Internet, como se muestra enla figura 6.14, que se refiere al tecnología ADSL(Asymmetric DSL), que es la tecnologíaxDSL más popular.

ADSL se denomina “asimétrica” porque las capacidades de descarga o de bajada (dela red hacia el usuario) y de subida (en sentido inverso) de datos no coinciden. La tecno-logía ADSL está diseñada para que la capacidad de bajada sea mayor que la de subida,ideal para servicios de red “cliente-servidor” en los que el cliente (el usuario) solicita unservicio, por ejemplo la descarga de una página web y el servidor, por ejemplo el servidorWeb, la envía. La consulta requiere de mucho menos capacidad que la transferencia delcontenido.

En ADSL, el ancho de banda dedicado a la transferencia de datos se divide en hasta256 subportadoras (las espigas rectangulares de la figura). Típicamente cada una es uncanal de 4 kHz con modulación QAM. En principio, cada una puede transportar hasta60 kbps (4000 baudios, con 15 bits por baudio). Si una subportadora tiene mucho ruido,ésta deja de utilizarse (las espigas blancas de la figura), lo que reduce la velocidad detransmisión del medio.

5CPE, Customer Premises Equipment, se trata del modem que instala el operador.

Diseño y Arquitectura de Redes Telemáticas 143

Page 154: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Figura 6.14: Tecnología ADSL

Como se ha mencionado, ADSL es la más popular de las tecnologías xDSL, peroexisten muchas otras. La siguiente tabla muestra las características de velocidad teóricasde algunas de las más populares.

ADSL HDSL ADSL2+ VDSLAsymmetric High Bit Rate Asymmetric Very High Speed

DSL DSL DSL DSLDe la red 256 kbps 1,168 kbps 25 Mbps 13, 42, 200 Mbpsal usuario

Del usuario 64 kbps Simétrico 1 Mbps 1, 5, 6 Mbpsa la red 1.5 Mbps

Distancia 2.5 km Hasta 4 km 1 km 52 Mbps 750 m

Dentro de las ventajas de esta tecnología se encuentran la recuperación del costo dedespliegue del par de abonado, la retención del ARPU (Average Revenue per User, ingresomedio por suscriptor), su bajo costo y su ubicuidad. Además, ofrece la posibilidad dehablar por teléfono al mismo tiempo que se navega por Internet.

Un gran inconveniente de ADSL es que la velocidad del servicio está limitada porvarios factores, como la calidad del cable y la distancia hasta la central telefónica, asícomo por el número de pares que viajan juntos en el ducto. Además, en muchos países elmarco regulatorio puede limitar la desagregación del par6, lo que representa una barrerade entrada a la competencia.

Otro inconveniente de ADSL es que los enlaces asimétricos pueden ser inadecuadospara las características de los usuarios contemporáneos, como lo muestra la figura 6.15obtenida de tráfico en un servidor de Twitter.

6Desagregación del bucle local, o del par trenzado, se refiere a un lineamiento que permite que distintosoperadores puedan ofrecer sus propios servicios (voz, datos, video) por el par trenzado a pesar de no habersido ellos quienes lo desplegaron.

Diseño y Arquitectura de Redes Telemáticas 144

Page 155: Diseño y Arquitectura de Redes Telemáticas

6.2. TECNOLOGÍAS DE ACCESO

En un entorno más familiar, jamás se debería poner un servidor local a través de unenlace asimétrico.

Figura 6.15: Tráfico simétrico en Internet

Cable módem

El cable módem es un tipo especial de módem diseñado para modular y demodular laseñal de datos sobre una infraestructura de televisión por cable. Se utiliza principalmentepara distribuir el acceso a Internet de banda ancha, aprovechando el ancho de banda queno se utiliza en la red de televisión por cable.

Figura 6.16: Cable módem

Esta tecnología presenta las ventajas de que el cable es de mayor calidad que el partrenzado. Bajo la norma DOCSIS 3.1, se pueden alcanzar velocidades de 10 Gbps en elcanal descendente y 1 Gbps en el ascendente, en condiciones ideales.

La principal desventaja es que los abonados de un mismo vecindario comparten el an-cho de banda proporcionado por una única línea de cable coaxial. Por lo tanto, la velocidad

Diseño y Arquitectura de Redes Telemáticas 145

Page 156: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

de conexión puede variar dependiendo de cuántos equipos están utilizando el servicio almismo tiempo.

Otras desventajas son las inversiones necesarias para modificar la infraestructura paraservicios digitales bidireccionales, y que el unbundling (la desagregación de servicios)puede ser legalmente complicado pues frecuentemente estas redes se despliegan con lospropios recursos de los operadores (lo que no necesariamente fue cierto al desplegar lasredes telefónicas a principios del siglo XX).

PLC (Power Line Communications)

Se refiere a un conjunto de tecnologías para ofrecer acceso a través de los cables deenergía eléctrica. El servicio se ofrece a través de la red eléctrica de baja tensión (110-380V) por medio de unidades acondicionadoras que filtran y separan las señales eléctricay de datos.

Como red de acceso, esta tecnología, también llamada BPL (Broadband over PowerLines), prometía ser una alternativa a las redes de DSL y de cable módem aprovechandoque la cobertura de la red eléctrica es mayor que la de las redes telefónicas y de cable.

Desgraciadamente, las señales de datos causan interferencia en las bandas de 3 a 30MHz y prácticamente ha sido abandonada como red de acceso, aunque en los últimosaños se observa un interés creciente en aplicaciones emergentes de Internet de las cosas(IoT) que no requieren de transferencias de datos a alta velocidad.

En cambio, HomePlug (HP) es una variante utilizada para desplegar redes localesdentro de los hogares ha logrado una gran aceptación en el mercado. Su última versión,AV2 puede alcanzar hasta 500 Mbps, más que suficiente para transportar flujos de videode alta definición dentro de los hogares.

HomePlug es desarrollada por CEPCA (Consumer Electronics Powerline Communi-cations Alliance). Por su parte, ITU desarrolla un nuevo estándar G.9960 conocido co-mo G.hn. Pretende utilizar cualquier medio de cobre en el hogar (cable telefóncio, cablecoaxial de TV y las líneas eléctricas de corriente alterna) para transmitir datos a tasas dehasta 1 Gbps.

Redes de fibra e híbridas

Una red híbrida HFC (Hybrid Fiber Copper) incorpora fibra óptica y cable coaxialpara crear una red de banda ancha. Esta tecnología se implementa típicamente comoevolución de las redes de televisión por cable para soportar la demanda creciente ddetransferencia de datos y más canales de video de alta definición.

Este tipo de red busca aprovechar las ventajas de cada tecnología que la conforman.Los hilos de fibra óptica permiten la cobertura de largas distancias con un mínimo deamplificación y regeneración de la señal, sin embargo, debido al costo y dimensiones delos multiplexores y demultiplexores ópticos, no se suele conectar directamente a los nodosde clientes; la fibra es conectada a un gateway el cual contiene al menos un transformador

Diseño y Arquitectura de Redes Telemáticas 146

Page 157: Diseño y Arquitectura de Redes Telemáticas

6.2. TECNOLOGÍAS DE ACCESO

Figura 6.17: Esquema PLC

óptico que permite la transición de la señal a la red de cable coaxial. El cable coaxialpermite que la señal llegue a los equipos terminales.

Las limitaciones de estos sistemas son que la señal puede necesitar ser amplificada yel sistema puede ser susceptible a interferencias externas.

Figura 6.18: Diagrama de una red HFC

Redes FTTx La fibra hasta el punto x (Fiber To The x) se refiere a un conjunto detecnologías de telecomunicaciones que se basan en la utilización de hilos de fibra ópticay sistemas de distribución ópticos para ofrecer servicios avanzados a hogares y negocios.Este tipo de tecnología presenta características muy deseables, como:

Alta inmunidad a la interferencia electromagnética

Enorme ancho de banda para grandes distancias

El costo de la fibra es del mismo orden que el cobre, aunque los despliegues, inter-faces y OAM (Operación, Administración y Mantenimiento) son más costosos

Diseño y Arquitectura de Redes Telemáticas 147

Page 158: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Debido a estas ventajas, los despliegues de fibra han crecido enormemente en los últi-mos años. La figura 6.19 muestra que las tecnologías que mayor crecimeinto tuvieron de2017 a 2018 son FTTH (23.2 %) y otros despliegues de fibra (5.3 %), esto en detrimento,sobre todo, de los despliegues en par trenzado, que tuvieron una caída de -7.1 %.

Figura 6.19: Crecimiento de suscriptores por tecnología

Para finales de 2018, la región dominante en despliegues de fibra óptica son los paísesasiáticos donde la cobertura se acerca al 90 % de hogares y edificios (figura 6.20).

Figura 6.20: Número total de suscriptores a FTTx en el mundo

Este fenómeno está ocurriendo en casi todos los países desarrollados y la mayoríaya han entrado a la etapa de crecimiento acelerado de las características curvas “S” deabsorción tecnológica (que retomaremos en el capítulo 7). La figura 6.21a muestra el cre-cimiento de suscriptores en España de 2007 a 2017 y la figura 6.21c la de Estados Unidosde 2001 a 2010. Llama la atención tanto el parecido de las curvas como los númerosabsolutos en ambos países.

Diseño y Arquitectura de Redes Telemáticas 148

Page 159: Diseño y Arquitectura de Redes Telemáticas

6.3. TECNOLOGÍAS DE ACCESO INALÁMBRICAS

(a) Penetración de FTTH en España

(b) Hogares visitados en EUA (c) Hogares atendidos en EUA

Figura 6.21: Penetración FTTH en España y EUA

Cabe mencionar que los Estados Unidos se vieron beneficiados por agresivas políticaspúblicas como el USA Recovery and Reinvestment Act, que destinó más de 7 mil millonesde dólares para fomentar el despliegue de fibra óptica durante la administración de BarakObama. Este tipo de iniciativas permitió que una gran cantidad de hogares tuvieran laposibilidad de contratar accesos en fibra (figura 6.21b) aunque menos de la tercera partelo haya hecho (figura 6.21c).

6.3. Tecnologías de acceso inalámbricas

Las tecnologías inalámbricas utilizan una señal radioeléctrica (una portadora) paratransmitir información modificando algunas de sus propiedades (frecuencia, fase o ampli-tud). Como redes de acceso a Internet, las tecnologías inalámbricastienen la gran ventajade que es mucho más rápido y económico levantar una torre y colocar antenas de co-municaciones, que hacer tendidos de cable en postes o ductos en ciudades y en zonasrurales.

Esta flexibilidad ayuda a explicar porqué las tecnologías inalámbricas han tenido unavance sorprendente en los últimos años. De hecho, si se extendieran las curvas mostradas

Diseño y Arquitectura de Redes Telemáticas 149

Page 160: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

en la figura 6.22, las velocidades ofrecidas por las tecnologías cableadas e inalámbricasconvergerían hacia el año 2030.

Figura 6.22: Velocidades de tecnologías de acceso

La realidad es que es difícil creer que esto sucederá, pues las tecnologías inalámbri-cas se enfrentan a muchos retos, como la relativa escasez de espectro radioeléctrico y lagran variabilidad de las capacidades de estas tecnologías, en función de la frecuencia queutilicen para su transmisión.

Por ello, es claro que no se tendrá “una gran tecnología dominante” sino una serie desoluciones tecnológicas que atienden diferentes nichos con distintas necesidades. La figu-ra 6.23 muestra una panorámica de las tendencias tecnológicas en función de dos criterios:movilidad y velocidad de transmisión.

Figura 6.23: Evolución de tecnologías inalámbricas

Diseño y Arquitectura de Redes Telemáticas 150

Page 161: Diseño y Arquitectura de Redes Telemáticas

6.3. TECNOLOGÍAS DE ACCESO INALÁMBRICAS

Tratando de presentar de manera sencilla conceptos que técnicamente son relativa-mente complejos, siempre encontramos un compromiso entre la cobertura (qué tan lejospuede propagarse) y la capacidad (qué tasa de transferencia ofrece) de una red. Por ejem-plo, en la figura 6.24 ubicamos algunas de las tecnologías inalámbricas más populares enfunción de su tasa de transmisión y su cobertura.

Figura 6.24: Sistemas inalámbricos en cobertura vs capacidad

La curva envolvente de la figura anterior es llamada Equi-cost/Equi-power porque unelemento clave del alcance y de la calidad de la señal (y por tanto, de la tasa de trans-misión), es la potencia de transmisión la cual puede estar limitada por el costo (a mayorpotencia, mayor costo) o por aspectos regulatorios para evitar daños a la salud o interfe-rencias a otros servicios.

Dos factores que afectan la propagación de una señal radioeléctrica son la frecuenciade la señal y la distancia entre el emisor y el receptor. La fórmula simplificada de Friis(figura 6.25) muestra cómo es esta relación en términos de la potencia recibida: Es direc-tamente proporcional a la potencia transmitida e inversamente proporcional al cuadradode la distancia y de la frecuencia.

Prx = Ptx{1

f × d}2

Figura 6.25: Fórmula simplificada de Friis

En las frecuencias más altas, la longitud de onda es del orden de las moléculas de aguaen la atmósfera y la energía de la señal es parcialmente absorbida pór éstas (y por otrosobjetos); en cambio, portadoras en frecuencias más bajas, como las bandas de 600 y 700MHz, hasta pueden atravesar paredes sin sufrir una atenuación tan alta. En la figura 6.26 semuestra cómo este efecto tiene un impacto en la cobertura de una radio base transmitiendocon la misma potencia en distintas frecuencias, en una zona urbana. Mientras que a 900MHz se cubre con una calidad aceptable un área con un radio de 1.5 km, a 3.5 GHz estacae a menos de 500 metros.

Como la potencia de recepción disminuye con la distancia, la relación señal a ruido(SNR, Signal-Noise-Ratio) disminuye drásticamente. Por ello, informalmente, la energíaque debe tener un bit en un símbolo debe ser mayor; más formalmente, la “eficiencia

Diseño y Arquitectura de Redes Telemáticas 151

Page 162: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Figura 6.26: Efecto de la frecuencia en el área cubierta por una radio base

espectral” disminuye con la distancia, como se muestra en la figura 6.27. La figura muestracómo debe utilizarse un modulador con menor densidad conforme aumenta la distancia.Las distintas curvas son para diferentes tipos de receptor en las instalaciones del usuario(CPE, Customer Premises Equipment).

Figura 6.27: Densidad del modulador enfunción de la distancia

Figura 6.28: Tasa de transmisión vs dis-tancia

El hecho de que se utilice un modulador con menor eficiencia espectral es lo queexplica que la tasa de transmisión disminuya conforme nos alejamos del AP en las redesWiFi o de la radio base en las redes celulares, como se muestra en la figura 6.28.

Resumiendo, la tasa efectiva estará afectada por la potencia del transmisor, la distan-cia del receptor y la frecuencia de la portadora. Es claro que también se verá afectada porobjetos que obstruyan la trayectoria entre transmisor y receptor, la ganancia de la antenadel receptor (que depende de su tamaño, entre otros factores) y, de manera muy impor-tante, de la cantidad de espectro (“el tamaño del bloque”) que el regulador del espectroradioeléctrico en un país (en nuestro caso, el Instituto Federal de Telecomunicaciones),otorgue para el servicio de comunicación inalámbrica de que se trate.

La siguiente tabla muestra características de equipos receptores CPE (Customer Pre-mises Equipment) para cierta tecnología inalámbrica fija, por ejemplo, WiMAX. Con unCPE situado en el exterior (por ejemplo, en la azotea de una casa), es de esperar que se

Diseño y Arquitectura de Redes Telemáticas 152

Page 163: Diseño y Arquitectura de Redes Telemáticas

6.3. TECNOLOGÍAS DE ACCESO INALÁMBRICAS

pueda tener un enlace sin obstrucciones (llamado “línea de vista”) entre emisor y receptor.Además, la antena del receptor puede ser de tamaño relativamente grande, con una ganan-cia sustancial. En cambio, un AP en el interior recibe una señal atenuada por paredes yotros obstáculos. Lo mismo ocurre con un receptor USB el cual, además, tiene una antenamuy pequeña y con una ganancia muy pobre.

Tabla 6.1: Porcentaje de cobertura en función del tipo de receptor. El radio de la celda esde 20 km y el área de cobertura de 1, 256 km2

Tipo CPE Rango de alcance % coberturaExterior 20-25 km 100 %Interior 10.6 km 53 %

USB 2.8 km 14 %

En la figura 6.29 ejemplifica cómo los factores anteriores tienen un impacto profundoal desplegar un sistema de comunicaciones en distintos entornos: En función de la fre-cuencia, el área de cobertura, el tamaño del bloque y las características del entorno, elnúmero de radiobases requerido para desplegar el sistema varía drásticamente.

Como se explicará más adelante, en una zona urbana densa, no merece la pena tenerfrecuencias bajas con bloques pequeños, pues el factor determinante es la densidad deusuarios. Una radio base con un bloque pequeño rápidamente se saturará por la demandade los usuarios, por lo que habrá que desplegar muchas más radio bases, reduciendo supotencia de transmisión para que no se genere interferencia entre ellas. En cambio, enunza zona rural, hay muy pocos usuarios, y se tenderá a privilegiar el uso de frecuenciasque cubran la máxima distancia posible.

Figura 6.29: Despliegue de estaciones base en área metropolitana

A continuación se presentan brevemente algunas de las tecnologías de acceso inalám-bricas más populares en la actualidad.

Acceso satelital

La idea de tener una estación de relevo para telecomunicaciones (un “espejo”) en elespacio fue propuesta por el científico y escritor Arthur C. Clarke y por Vahid K. Sanadi

Diseño y Arquitectura de Redes Telemáticas 153

Page 164: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

en los años 40. Unos años más tarde, la Marina de Estados Unidos realizó varias pruebasde concepto en proyectos de espionaje utilizando a la luna, nuestro satélite natural, comoespejo para captar las señales emitidas por los radares soviéticos.

El primer satélite artificial lanzado exitosamente fue el satélite ruso Sputnik I, en 1957.No se utilizó para sistemas de telecomunicaciones pero permitió validar la factibilidadtécnica de esta tecnología. Un año más tarde la NASA manda fabricar el primer satélitediseñado como relevo de telecomunicaciones dentro del proyecto SCORE.

Los satélites para telecomunicaciones más comunes se encuentran en la llamada “ór-bita de Clark” en honor a Arthur Clark, a 35,784 km (≈ 36, 000km) sobre el nivel del mar(snm) en el ecuador. A esa altura, las fuerzas centrífuga y centrípeta están en equilibrio yel satélite tiene la misma velocidad angular que la rotación de la tierra, por lo que parecen“fijos” en el espacio para un observador terrestre. Se les llama satélites geo-estacionarioso GEO (Geo-stationary earth orbit).

Todos los satélites dedicados a difusión de radio y televisión y muchos de los utiliza-dos para acceso a Internet son GEO, pues entre sus ventajas está el hecho de que una vezorientada la antena hacia el satélite, ya no tiene que ajustarse.

Los satélites GEO poseen otras ventajas, como el hecho de que, en principio, consólo tres satélites se podría cubrir casi toda la superficie terrestre, como se muestra en lafigura 6.30a.

Los satélties GEO tienen varias limitantes. En primer lugar, es que es muy costosoy complejo colocar un satélite a esa altitud. Además, se requiere de antenas relativa-mente grandes y de una potencia de transmisión sustancial para que la comunicaciónpueda llevarse a cabo. Por ello, el uso de satélites GEO para comunicaciones en smartp-hones, es sencillamente imposible. Por último, la latencia imposibilita comunicacionesbi-direccionales en tiempo real.

Los satélites MEO (Medium-earth Orbit) operan órbitas entre 5,000 y 12,000 kmsnm. Su diseño es más simple y su puesta en órbita mucho menos costosa. Se utilizanpara aplicaciones como monitoreo y fotografiado terrestre, monitoreo atmosférico y paraaplicaciones militares.

Se han llegado a utilizar como sistemas de comunicaciones, pero ello implica el usode antenas especiales que van siguiendo la órbita de un satélite, y del relevo de la comu-nicación entre algunos de ellos, que forman una constelación.

Los satélites LEO (Low-earth orbit) operan a distancias de 500 a 1,500 km snm. Aesa distancia, la latencia es bastante reducida; además, se pueden utilizar antenas de bajapotencia (alrededor de 1 Watt). Sin embargo, su cobertura es muy limitada, por lo que sedeben desplegar constelaciones de alta densidad (decenas de satélites, como se muestraen la figura 6.30b) y el relevo entre ellos es muy complejo.

Su tiempo de vida es muy corto (5 a 8 años). Si una constelación tiene 50 satélites,se tendría que estar renovando un satélite cada dos meses, lo que hace que estos sistemastengan un costo de operación muy alto.

Como tecnologías de acceso, los satélites GEO de los años 90 operaban en la banda de

Diseño y Arquitectura de Redes Telemáticas 154

Page 165: Diseño y Arquitectura de Redes Telemáticas

6.3. TECNOLOGÍAS DE ACCESO INALÁMBRICAS

(a) Satélites geo-estacionarios (b) Constelación de satélites LEO

Figura 6.30: Sistemas satelitales

frecuencias “C” (4 a 6 GHz) con anchos de banda de 36 a 72 MHz y ofrecían velocidadesde acceso de 128 kbps a 2 Mbps.

En la última década se ha hecho popular el uso de la banda Ku (11 a 14 GHz) conanchos de banda más granades. Junto con sofisticadas tecnologías de compresión y codi-ficación, estos satélites permiten velocidades de bajada de cientos de Mbps.

Aunque el servicio de acceso a Internet es sustancialmente más costoso que con lasotras tecnologías de acceso, los satélites artificiales garantizan conectividad en zonas don-de ninguna otra tecnología es factible, como en aviones, océanos, montañas o zonas de-sérticas.

Para reducir los costos de los equipos terminales en enlaces satelitales GEO, se hanpopularizado los sistemas con antenas VSAT (Very small apperture terminal). En éstos,las antenas de los equipos terminales son comparativamente muy pequeñas (70 cm a 1.5mt). Dado que estas antenas tienen una ganancia muy baja, la comunicación entre dosusuarios pasa a través de un nodo central (un hub, figura 6.31) con una antena mucho másgrande (4 a 10 metros) que permite una gran amplificación de la señal. Desgraciadamente,esto hace que se duplique la latencia, pues el mensaje va del emisor al satélite, de éste alhub, nuevamente al satélite y finalmente al destinatario.

A pesar de que la gran mayoría de los proyectos de constelaciones satelitales LEOde los años 90 fueron un gran fracaso comercial, en los últimos 5 años ha resurgido elinterés por estos sistemas y empresas como SpaceX, Amazon y OneWeb están invirtien-do miles de millones de dólares para desplegar constelaciones con cientos de satélitesintercomunicados entre sí a través de enlaces láser.

HAP (High Altitude Platform)

Las estaciones HAP consisten en vehículos típicamente no tripulados a una altitud de20 a 50 km en un punto específico relativo a la tierra. Tienen muchos usos en aplicacionesmilitares y de monitoreo remoto. Para telecomunicaciones, se trata de estaciones de relevo

Diseño y Arquitectura de Redes Telemáticas 155

Page 166: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Figura 6.31: Sistema VSAT

que ofrecen una excelente alternativas para regiones donde no hay servicio terrestre osatelital. También pueden ser desplegados rápidamente para dar cobertura en áreas quehan sido afectadas por desastres naturales.

Las tecnologías HAP se empezaron a probar a principios de los años 90, principal-mente para aplicaciones militares. A finales de los años 90 el interés por estas tecnologíasfue tal, que la Unión Internacional de Telecomunicaciones asignó bandas de frecuenciaespecíficas para servicios HAP: 2 GHz en la banda 47/48 GHz y 6 GHz en la banda 27/31GHz.

Potencialmente, las HAP ofrecen muchas ventajas: Mayor cobertura y menor tiempode despliegue que un sistema basado en radio-bases, y por supuesto, con menor interferen-cia. Con relación a los sistemas satelitales, su costo es mucho menor así como la latencia.Además, se pueden regresar fácilmente a tierra para su reparación y actualización.

Por estas razones, se esperaba que las HAP fueran una atractiva alternativa para tec-nologías de acceso a Internet. En la década pasada, hubo muchos proyectos para evaluarsu factibilidad en Japón, Corea del Sur, Brasil, la Unión Europea y Estados Unidos. Sinembargo, de las decenas de proyectos documentados, sólo continuaron tres: Los proyec-tos LOON de Google (actualmente en suspensión), Aquila de Facebook (que se ha aliadocon Airbus) y Zephyr de Airbus (figura 6.32).

Algunas de las razones por las que estas tecnologías no han sido desplegadas son elhecho de que, a pesar de que tienen un costo sustancialmente menor que los satélites, loscomponentes de los HAPs son sofisticados, pues deben soportar condiciones de operaciónmuy adversas y tener una alta tolerancia a fallos. En zonas urbanas otras alternativas deacceso son más atractivas y en zonas aisladas, el modelo de negocio los hace inviables.

Por otra parte, varias de las pruebas de concepto se cancelaron por fallos en los vehícu-los no tripulados, lo que representa un serio riesgo de seguridad en zonas pobladas.

Diseño y Arquitectura de Redes Telemáticas 156

Page 167: Diseño y Arquitectura de Redes Telemáticas

6.3. TECNOLOGÍAS DE ACCESO INALÁMBRICAS

Figura 6.32: Plataforma no tripulada Zephyr de Airbus

Radios cognitivos

Tradicionalmente se ha considerado que el espectro radioeléctrico es un recurso esca-so que debe ser regulado. La forma en que esto suele hacerse, es concesionando bloquesde espectro para usos específicos. Por ejemplo, el rango de frecuencias de 87.5 MHz a108 MHz, está contemplado para concesionarios de radiodifusión en FM, mientras quela banda de 1.9 GHz es una de las frecuencias utilizadas por concesionarios de telefoníacelular.

Sin enmbargo, el espectro es un recurso particular pues no se desgasta con su uso.Además, mientras las frecuencias para unos servicios pueden estar saturadas (por ejemplo,telefonía celular) otras bandas pueden estar seriamente subutilizadas (por ejemplo, bandaspara radio aficionados, difusión de TV en ultra alta frecuencia y frecuencias para usomilitar).

Con el fin de aprovechar mejor el espectro y dejar atrás la percepción de que se tratade un “recurso escaso”, nace la idea de utilizar radios cognitivos (CR, cognitive radio). Setrata de dispositivos que pueden ser configurados dinámicamente para utilizar las bandasde frecuencia disponibles en su entorno y si se detecta que éstas empiezan a ser utiliza-das (por otros CR o por los concesionarios de la banda), el radio puede brincar a otrasfrecuencias libres. De esta manera, se consigue lo que se conoce como gestión dinámicadel espectro.

Las primeras propuestas de CR eran un subconjunto de los “radios definidos por soft-ware”. El dispositivo sensa su entorno; si encuentra una banda que aparentemente estélibre, calcula cuánta energía generaría su transmisión y si ésta no rebasa un umbral llama-do “temperatura de interferencia” (figura 6.33), transmite en esa banda; de lo contrario,busca otro canal.

Se ha encontrado que es sumamente complicado implementar dispositivos basadosen la idea de sensar el entorno y calcular la temperatura de interferencia para estableceruna red de comunicaciones confiable. Se requiere de nuevos protocolos y algoritmos paraestimar de manera confiable qué bandas podrían ser utilizadas sin generar interferencia.

Una alternativa, surgida en el Reino Unido y ampliamente aceptada, sobre todo paraaprovechar los bloques de espectro asignados a difusión de televisión abierta, es la cono-

Diseño y Arquitectura de Redes Telemáticas 157

Page 168: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

Figura 6.33: Temperatura de interferencia

cida como “espacios blancos” (white spaces). La idea básica es que el regulador sabe quéfrecuencias ha asignado en qué regiones, y por lo tanto, cuáles quedan libres en esa región(figura 6.34). El dispositivo tiene un módulo de geolocalización y cuando desea estableceruna comunicación, determina su ubicación, consulta la base de datos del regulador y seauto-configura para utilizar alguana de las bandas que están libres en su entorno.

Figura 6.34: Radio cognitivo

El grupo de trabajo IEEE 802.22 ha definido estándares para desplegar redes de árearegional (hasta 100 km con baja densidad de población) con base en la tecnología deradios cognitivos con espacios blancos. En Estados Unidos, la base de datos del órganoregulador que consultan estos radios es administrada por Google.

La IEEE también ha definido el estándar IEEE 802.11af para desplegar redes localesinalámbricas con tecnología de espacios blancos. Se le conoce como White-Fi o SuperWi-Fi.

6.3.1. Telefonía celular

Como se ha mostrado al inicio de este capítulo, la penetración de Internet con tecno-logías inalámbricas ha tenido un crecimiento exponencial en todo el planeta. El principalmedio de acceso inalámbrico a Internet es la telefonía celular o móvil. En México, el cre-cimiento de líneas móviles por cada 100 habitantes ha rebasado el 90 % como se muestraen la figura 6.35. La penetración de la telefonía móvil ha sido tal que en algunos países halogrado desplazar hasta el 50 % de las líneas de telefonía fija.

Diseño y Arquitectura de Redes Telemáticas 158

Page 169: Diseño y Arquitectura de Redes Telemáticas

6.3. TECNOLOGÍAS DE ACCESO INALÁMBRICAS

Figura 6.35: Evolución de la teledensidad de líneas de telefonía móvil en México

Como se muestra en la tabla 6.2, desde la segunda generación de telefonía celular sehan contemplado tecnologías para facilitar la transferencia de datos en las redes móviles,y, eventualmente, proveer acceso a Internet.

Tabla 6.2: Evolución de generaciones detelefonía celular

GSM 14.4 kbps2G HSCSD 36.6 kbps

PDC, CDMA 64 kbps2.5G GPRS 115 kbps2.75G EDGE 384 kbps

3G UMTS 2 Mbps Figura 6.36: Aumento de demanda de trans-ferecncia

Las primeras generaciones de telefonía celular respondían razonablemente bien a lasnecesidades de teléfonos con pantallas sumamente pequeñas y capacidad de procesamien-to muy limitada. Con la llegada de los teléfonos inteligentes, y en especial con la introduc-ción de la familia de dispositivos móviles de Apple, el panorama cambió radicalmente,como se muestra en la figura 6.36.

Estos dispositivos en los que toda la superficie es una pantalla, basados en el uso deaplicaciones móviles (Apps) y que requieren de conexión constante (a veces, continua) aInternet rebasaron por mucho las capacidades de las redes celulares.

Ello llevó a los fabricantes y operadores a acelerar sus hojas de ruta y se dio un rá-pido despliegue de subgeneraciones (3.5G, 3.75G) que ofrecían mayores velocidades detransferencia, hasta llegar a las actuales redes 4G (LTE, Long Term Evolution) cuya prin-cipal característica es que son redes basadas en los principios de transferencia de datos(conmutación de paquetes), en las que la telefonía es un servicio más.

Para zonas donde las redes celulares están altamente congestionadas o la coberturaal interior de edificios es un problema, se han implementado alternativas ingeniosas quecomplementan el acceso a Internet a través de teléfonos inteligentes. Dos de ellas son lasfemto celdas y UMA que aparecen en la figura 6.37.

Diseño y Arquitectura de Redes Telemáticas 159

Page 170: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 6. TECNOLOGIAS DE ACCESO

(a) Modelo de Femto Celda. (b) Modelo Unlicensed Mobile Access

Figura 6.37: Alternativas para desfogar carga en redes celulares

Femto Celdas

FemtoCeldas Se trata de una pequeña estación base que proporciona tecnología celulardentro del hogar o la oficina. Se enlaza a la red del operador a través de cualquier tecnolo-gía de acceso disponible (típicamente una tecnología alambrada, como FTTH o ADSL).En esa red se establece una VPN con los equipos del operador para fines de administra-ción, tarificación, etcétera.

Los puntos de acceso utilizan las mismas frecuencias que las macro celdas, pero ope-ran a una potencia mucho menor para evitar interferencia. Algunas femto celdas permitenel relevo con las macro celdas (handover) sin perder la conexión, exactamente como ocu-rre con la itinerancia entre radio bases.

Con técnicas similares a las empleadas para planear el despliegue de redes WiFi, seeligen los puntos óptimos para la instalación de estos puntos de acceso, lo que permiteincrementar la capacidad a bajo costo y mejorar la cobertura en interiores.

Unlicensed Mobile Access Es el nombre comercial de una tecnología llamada GenericAccess Network (GAN). También se le llama Wi-Fi Calling, VoWiFi.

Dado que prácticamente todos los teléfonos móviles en la actualidad cuentan con laposibilidad de conectarse a redes WiFi, esta tecnología permite que los usuarios utilicenlos recursos de la red local cuando se encuentren dentro de su cobertura para acceder aInternet pero también para establecer llamadas telefónicas. Si el usuario sale del área decobertura de la red WiFi, la red celular se ocupará de hcer la transición a la radio base demanera transparente.

La principal diferencia entre las femto celdas y UMA/GAN, es que en este últimocaso, el relevo se hace transitando de una pila de protocolos (WiFi) a otra (GSM, UMTS,LTE) además de la transición del AP a la radio base. A esto se le conoce como “rele-vo vertical” (vertical handover) y requiere de dispositivos móviles que cuenten con estafuncionalidad.

Diseño y Arquitectura de Redes Telemáticas 160

Page 171: Diseño y Arquitectura de Redes Telemáticas

6.4. PROBLEMAS

WiMAX - IEEE 802.16

Worldwide Ineroperability for Microwave Access es una norma de transmisión de da-tos que pertenece a las tecnologías de última milla, utiliza las ondas radioeléctricas en lasfrecuencias 2,5 a 5,8 GHz y puede llegar a proveer una cobertura de hasta 70 km. En lasimplementaciones para cobertura móvil, WiMAX permite que los usuarios se desplacende manera similar que en las redes móviles convencionales (UMTS). También, las ca-racterísticas de WiMAX lo hacen adecuado para aplicaciones potenciales como acceso aInternet, backhaul o triple play. Una de sus mayores ventajas es que permite proveer ser-vicios de banda ancha a zonas con baja densidad poblacional que presentan altos costospor usuario. Una de las últimas implenetaciones de WiMAX (WiMAX2-IEEE 802.16m)tiene como objetivo alcanzar una velocidad de descarga de 100 Mbit/s, esto la da potencialpara el despliegue de tecnologías de cuarta generación.

Figura 6.38: Esquema de comunicación WiMAX

6.4. Problemas

6.1. Además de ADSL, identifique otras tres tecnologías de acceso, resaltando suprincipal ventaja y grado de madurez en México

6.2. ¿Por qué en un sistema de VSAT se debe recorrer el segmento terrestre-satélite4 veces?

6.3. ¿Aproximadamente cuál es la latencia de fuente a destino para una comunica-ción en los globos de Google? (Tip: un globo vuela más o menos a la altura de unHAP)

≈ 60µ s ≈ 130µ s ≈ 120ms ≈ 240ms

6.4. El perfil de Don Lencho en Internet es principalmente el de un consumidorde contenidos: Ve regularmente series y películas de Netflix y algunos videos deyoutube. En su localidad, solo tiene dos opciones: Contratar un enlace ADSL de5 Mbps con una renta mensual de $500.00, o un FTTH de 10 Mbps con una rentamensual de $800.00.

¿Qué le recomendarías? Justifica muy brevemente tu respuesta

Diseño y Arquitectura de Redes Telemáticas 161

Page 172: Diseño y Arquitectura de Redes Telemáticas
Page 173: Diseño y Arquitectura de Redes Telemáticas

Capítulo 7

Análisis tecno-económico

7.1. Introducción

Los proyectos de TI en general, y de infraestructura de redes en particular, deben sercoherentes con los objetivos de negocio y poder justificarse en términos financieros oestratégicos.

La empresa tiene objetivos tácticos o duros, que son cuantificables (objetivos “SMART”),tales como reducir costos, aumentar la productividad, o reducir el tiempo de lanzamien-to al mercado. También tiene objetivos estratégicos o suaves, los cuales son subjetivosy más difíciles de medir, como incrementar la eficiencia, obtener ventajas competitivassostenibles y facilitar una reingeniería de procesos de negocio.

En cualquier caso, al final del día se busca que el dinero empleado para el proyecto (yque se obtiene de un préstamo, de las utilidades, o de aportaciones de los inversionistas),se utilice con el fin de maximizar el retorno de la inversión para los accionistas.

En este capítulo se hace una muy breve introducción a las métricas financieras básicasutilizadas para analizar y justificar proyectos en las organizaciones, utilizando ejemplosde proyectos de TI. Posteriormente se muestran los elementos a considerar al hacer unanálisis tecno-económico de un proyecto de redes.

7.2. Métricas financieras

Las métricas financieras básicas para analizar inversiones en proyectos son las siguien-tes:

Costo total de propiedad (TCO, Total Cost of Ownership)

Periodo de recuperación (PBP, Pay Back Period)

Retorno de Inversión (ROI, Return On Investment)

Page 174: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Valor presente neto (NPV, Net Present Value)

Para proyectos específicos de TI algunas consultoras han propuesto métricas másespecializadas, como Rapid Economic Justification (REJ), Total Value of Opportunity(TVO) y Total Economic Impact (TEI). Estas métricas rebasan el alcance del curso.

7.2.1. Costo total de propiedad

El costo total de propiedad (TCO) tiene por objeto considerar de manera explícita loscostos incurridos durante TODO el ciclo de vida de la solución.

Cuando se tiene poca experiencia es común tomar en cuenta únicamente los costos deadquisición de las tecnologías involucradas (por ejemplo, la compra de equipo e infraes-tructura), pero el proyecto tiene costos a lo largo de toda su vida útil. Al menos se debentomar en cuenta los costos de las siguientes fases:

Los costos de adquisición se incluyen en el indicador conocido como CAPEX (Ca-pital Expenditures); los de operación, administración y mantenimiento (OA&M), en elOPEX Operational Expenditures).

A manera de ejemplo, podemos imaginar el costo total de poseer un automóvil. Ade-más del costo de adquisición del auto (el CAPEX), debemos tomar en cuenta los costosde tenencia, mantenimiento, consumo de gasolina, seguros, estacionamiento, etcétera. Enen un horizonte de tres años, estos costos pueden ser lo bastante onerosos como para notomarlos en consideración.

En algunos proyectos el OPEX puede ser el factor dominante, al grado que en oca-siones TCO se interpreta como Total Cost of “Operation”. En otro tipo de proyectos, elfactor dominante puede ser el CAPEX; para ellos a veces la métrica que se utiliza es TCA,Total Cost of Acquisition.

En proyectos de TI, como la adquisición de un ERP o un manejador de base de datos,el CAPEX suele representar entre 20 % y 30 % del costo total de operación en un horizontede 3 a 5 años.

En la actualidad, con la gran penetración del cómputo en la nube (cloud computing)estos términos se han puesto de moda, pues con la provisión de servicios de TI en la nubese reduce drásticamente el CAPEX (se dejan de comprar servidores, infraestructura de

Diseño y Arquitectura de Redes Telemáticas 164

Page 175: Diseño y Arquitectura de Redes Telemáticas

7.2. MÉTRICAS FINANCIERAS

soporte) y se aumenta el OPEX (se paga regularmente el arrendamiento de los servidoresvirtuales).

Dado que en el despliegue de grandes redes de comunicaciones los costos de imple-mentación iniciales pueden ser muy grandes, en este tipo de proyectos suelen especificarsede forma aislada como IMPEX, Implementation Expenditures. Aquí se incluyen costoscomo la adquisición del terreno, obra civil para instalaciones y levantamiento de la torre,el equipo de la estación base y antenas, etcétera).

Para calcular el TCO se deben incluir todos los elementos que puedan identificarse,como:

Hardware (servidores, instalación, configuración, planeación, modificaciones a lainfraestructura existente, ...)

Software (adquisición, licencias, configuración, mantenimiento, adaptaciones, cos-tos de estabilización, ...)

Capital humano (nuevo personal, capacitación, apoyo para instalación, gestión delcambio, ...)

Indirectos (arrendamiento del local y de los equipos, luz, probabilidad e impacto defallos, ...)

No es extraño que se aumente un margen (entre 10 % y 30 %) al TCO para incluircostos adicionales que no han sido claramente identificados.

EJEMPLO 7.1. 1 Se tienen tres alternativas para desplegar una red local: unared cableada (LAN); una red inalámbrica convencional basada en puntos deacceso (AP, Access Point) robustos distribuidos en las instalaciones (WLAN)y una red inalámbrica basada en un conmutador inteligente y puntos de accesomuy simples (repetidores) distribuidos en las instalaciones (Sw-WLAN).

El conmutador en la última opción, es muy poderoso e incorpora, de formacentralizada, muchas de las funcionalidades que se espera encontrar en unAP, como control de acceso, configuración de VLANs, asiganción dinámicade IPs, gestión de potencia de portadoras, etc. Sin embargo, es un equipo muycostoso; en cambio, los APs para esta red son muy sencillos y económicos.

El ambiente en el que se desplegará la red incluye 100 puestos de trabajo(100 computadoras) y es muy dinámico; se ha estimado que durante un año,alrededor del 30 % de los puestos de trabajo deben re-ubicarse. Si durante estareubicacion se pierde conectividad con la red, ese puesto de trabajo tendrá unapérdida de productividad estimada en $50 USD por año2.

1Los ejemplos en esta sección son sumamente triviales con el fin de asimilar el concepto sin perdernosen los detalles. Una estimación de TCO formal tomaría en consideración muchos más elementos.

2Los costos en este ejemplo están en dólares americanos y fueron estimados a valor de mercado en 2007

Diseño y Arquitectura de Redes Telemáticas 165

Page 176: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Las computadoras en los puestos de trabajo incluyen una tarjeta de red ca-bleada; si se desea desplegar una red inalámbrica, se deben adquirir nuevastarjetas de red. Las siguientes tablas muestra los costos que se toman en cuen-ta para este ejemplo:

Red AlambradaComputadoras 100Tarjeta de red $0Costo del conmutador por puerto $20Instalación por puerto $400Reinstalación por puerto $200Porcentaje de reubicación por año 30 %Pérdida de productividad $50Herramientas de administración $4,000OA&M y licencias por año $200

WLAN Sw-WLANAPs 20 20Costo AP $300 $100Instalación AP $250 $250Tarjeta de red $75 $75Conmutador $0 $10,000Herramientas de administración $4,000 $2,000Herramientas Ctl. acceso $5,000 $2,500OA&M y licencias por AP por año $250 $150Gestión de radio frecuencia por AP por año $200 $50

Los costos de adquisición de las tres alternativas son los siguientes:

LAN :(100)($20) + (100)($400) + $4, 000 = $46, 000

WLAN :(20)($300) + (20)($250) + (100)($75) + $0 + $4, 000 + $5, 000 = $27, 500

Sw-WLAN :(20)($100) + (20)($250) + (100)($75) + $10, 000 + $2, 000 + $2, 500 = $29, 000

Considerando el CAPEX, parecería que la opción de la red local inalámbricaconvencional es la más atractiva, y es que el costo del conmutador en la Sw-WLAN es muy elevado.

Los gastos de instalación en la red cableada son muy altos, pues suponen eltendido de canaletas y cables a lo largo de la empresa. En un edificio concableado estructurado, estos costos disminuirían considerablemente.

Veamos ahora los costos de operación, administración y mantenimiento (OA&M)

Diseño y Arquitectura de Redes Telemáticas 166

Page 177: Diseño y Arquitectura de Redes Telemáticas

7.2. MÉTRICAS FINANCIERAS

por año:

LAN :(0.3)(100)($200) + (0.3)(100)($50) + (100)($200) = $27, 500

WLAN :(0.3)(100)($0) + (20)($250) + (20)($200) = $9, 000

Sw-WLAN :(0.3)(100)($0) + (20)($150) + (20)($50) = $4, 000

El OPEX anual de la red local con conmutador inteligente es menos de lamitad que el de la red inalámbrica convencional; las funcionalidades del con-mutador empiezan a rendir frutos. Los dos son mucho menores a los de la redcableada porque en la reconfiguración de puestos no se requiere de reinstala-ciones y no hay pérdida de productividad.

El costo total de operación a tres años, es mucho más favorable para la redinalámbrica basada en conmutador inteligente:

LAN : TCO =$46, 000 + 3($9, 000) = $128, 500

WLAN : TCO =$27, 500 + 3($9, 000) = $54, 500

Sw-WLAN : TCO =$29, 000 + 3($4, 000) = $41, 000

Una de las mayores dificultades para calcular el TCO en el despliegue de redes detelecomunicaciones, es que los costos pueden variar enormemente de una región a otra, yde un año a otro. Son mercados sumamente dinámicos.

Las siguientes cifras se presentan únicamente como referencia para tener una ideamuy somera de los costos de despliegue de este tipo de redes:

Despliegues de redes WiFi municipales en Estados Unidos. Si la red contemplaúnicamente servicios no públicos (servicios municipales) se estimaba que el OPEXera de 15 % del CAPEX por AP por año. Si la red ofrecía servicios públicos elOPEX se duplicaba pues se deben incluir costos de servicio a cliente, tarificación ymarketing, entre otros.

En algunas redes municipales el OPEX total fue 10 veces superior al CAPEX en unhorizonte de 5 años.

El arrendamiento de luminarias para instalar los APs variaba enormemente de unmunicipio a otro: En Louisiana costaba $86 USD por poste por año, mientras queen California el costo era de $36.

Los AP con calidad comercial para despliegues a la intemperie con un solo radio,gastaban $20 USD de energía eléctrica por año; los AP con dos radios (ideales paradespliegues de mallas WiFi municipales) gastan cinco veces más: $100 USD poraño.

Diseño y Arquitectura de Redes Telemáticas 167

Page 178: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Para despliegues de fibra al hogar (FTTH) en Canadá, se estimó un OPEX de 5 %del CAPEX por nodo.

Las siguientes figuras muestran los porcentajes de los rubros más importantes en CA-PEX y OPEX para el despliegue de una estación base de telefonía celular en EstadosUnidos a principios de este milenio.

Recordemos que estas cifras son únicamente un referente y que hay grandes variacio-nes dependiendo del contexto. Por ejemplo, en un país grande, el equipo de la red dorsalrepresenta 30 % del CAPEX, mientras que en uno pequeño, es sólo el 10 %. Sin embargo,la adaptación de los sitios en el primer caso cubren el 30 % del CAPEX, pero en los paísespequeños puede ascender hasta 50 %.

Es interesante observar que los costos relacionados con los equipos de telecomunica-ciones no son dominantes ni en CAPEX ni en OPEX, y, de hecho, la tendencia es queestos costos disminuyan con el teimpo.

En México, en áreas rurales, el costo de interconexión era en promedio el doble que lafigura anterior (18 %), pero en algunas regiones podía alcanzar hasta el 70 %, debido a laenorme variación en los costos de los enlaces dedicados: Un enlace E1 podía costar de $15a $15,000 USD mensuales. Estas variaciones explican buena parte de la gran variaciónen cobertura celular que tenía México, donde todavía hay un porcentaje sustancial decomunidades no atendidas y subatendidas.

Para tener una idea general de los costos de implementación, las siguientes figurasmuestran la distribución de costos para despliegues de redes LTE en un país nórdico en2012.

Sorprende la gran diferencia en TCO entre despliegues basados en macro-celdas (120,000e)y micro-celdas (22,000e). En el despliegue de micro-celdas, el componente más impor-

Diseño y Arquitectura de Redes Telemáticas 168

Page 179: Diseño y Arquitectura de Redes Telemáticas

7.2. MÉTRICAS FINANCIERAS

tante del OPEX es la interconexión entre celdas (backhaul) porque se deben desplegarmuchas más celdas para la misma zona.

Terminamos esta sección resaltando algunas características del TCO:

Es muy conocido desde que la consultora Gartner lo empezó a utilizar en la industriade TI a finales de los años 80.

Es el punto de partida de casi todos los estudios de rentabilidad

Es muy útil para comparar proyectos alternativos equiparables. Sin embargo, nodebemos olvidar que el objetivo de un proyecto es maximizar la rentabilidad de unainversión, no minimizar los costos.

El TCO no toma en cuenta el costo del capital. Esto es un riesgo financiero impor-tante para proyectos de alto costo y tiempo.

7.2.2. Retorno de inversión

El Retorno de inversión (ROI) es una técnica muy popular para estimar las consecuen-cias financieras al hacer una inversión o implementar un proyecto.

En su forma más simple, el ROI es el resultado de dividir los beneficios netos entre elcosto de la inversión, expresado en porcentaje.

ROI =(Beneficios− Costos

Costos× 100

Es una métrica muy popular que permite comparar la tasa de retorno esperada deun proyecto, contra otro tipo de inversión de capital, como puede ser un portafolio deinversión. Esta métrica debe considerar un horizonte de tiempo. Para proyectos de TI,este horizonte suele ser de 3 a 5 años.

Con frecuencia se utiliza para comparar la tasa de retorno del proyecto contra otrotipo de inversión de capital; por ejemplo, decidir adquirir un nuevo servidor, o invertir eldinero en un instrumento financiero.

Para calcular el ROI se deben tratar de identificar todos los beneficios y costos delproyecto. Para el cálculo de costos, se deben incorporar las reflexiones presentadas en elanálisis del TCO.

La estimación de los beneficios se complica porque existen distintos tipos de bene-ficios, como tangibles, estratégicos y algunos, como los financieros, pueden cambiar enfunción de las políticas económicas de un país. Un buen punto de partida (y un gran retoen muchas empresas), es tratar de identificar los llamados KPI,Key Performance Indica-tors.

Estos son algunos ejemplos de beneficios a considerar cuando se calcula el ROI:

Diseño y Arquitectura de Redes Telemáticas 169

Page 180: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Beneficios cuantificables (hard) : Reducción en el ancho de banda en los accesos a Inter-net; consolidación de servidores físicos; reducción en los tiempos de procesamientoy en los tiempos de lanzamiento al mercado de una nueva aplicación;

Beneficios cualitativos (soft) : Mejora la productividad y eficiencia de los empleados;mejora el ambiente laboral; aumenta la fidelización de los clientes; mejora la repu-tación de la marca

Beneficios en ingresos : Aumento de la producción; mayor participación de mercado;Incremento en el ingreso medio por cliente (ARPU, Average Revenue Per User)

Los beneficios cualitativos se les llama soft porque no pueden convertirse directamenteen un valor económico. Por ejemplo, el aumento en la productividad de un empleado nonecesariamente implica una aumento en la producción ni una reducción en el númerode empleados. En general, se debe recurrir a profesionales de otras áreas (por ejemplo, aldirector de RH, de marketing, de operaciones) para que ayuden a convertir estos beneficiosen términos cuantitativos.

Al estimar el horizonte de tiempo para el cálculo del ROI también deben tomarse enconsideración los cambios (realistas) esperados durante ese tiempo, como pueden ser elincremento en ingresos (por ejemplo, por una mayor captación de clientes) y en gastos(por ejemplo, por un aumento en los recursos asignados a los centros de atención a clien-tes).

Por ello, aunque se recomiendan horizontes de tiempo de tres a cinco años para pro-yectos de TI, en ocasiones el ROI se calcula para dos o tres años. Una excepción notablees el cálculo de ROI para redes de comunicaciones. Las inversiones iniciales suelen sertan grandes, que los proyectos no son rentables antes de 7 o 10 años; en estos casos, loscálculos consideran horizontes de tiempo de 10, 15 o 20 años.

EJEMPLO 7.2. Una empresa está considerando implementar un CRM conel que espera tener una interacción mucho más fluida con sus clientes. Através de esta interacción estima que tendrá una gran fidelización (una tasade abandono, CHURN, menor) y la oportunidad de lanzar más y mejorsesservicios al mercado en menos tiempo.

Al analizar el proyecto con las distintas unidades de negocio, se encontraronlos siguientes beneficios. Observe que casi todos están expresados como unareducción en costos y que se está haciendo una estimación de mejoras a lolargo del tiempo gracias a la implementación del CRM.

Beneficios (Millones USD) Año 1 Año 2 Año 3Reduce costos de transacción $ 2.50 $ 3.00 $ 3.20Reduce costos de operación $ 0.80 $ 1.00 $ 1.10Reduce costos de TI – $ 1.50 $ 1.50Reduce CHURN $ 3.50 $ 4.00 $ 5.00Reduce time to market – $ 2.50 $ 2.50

TOTAL: $ 6.80 $ 12.00 $ 13.30

Diseño y Arquitectura de Redes Telemáticas 170

Page 181: Diseño y Arquitectura de Redes Telemáticas

7.2. MÉTRICAS FINANCIERAS

La empresa espera un beneficio total $6.80 + $12.00 + $13.30 = $ 32.10 enlos tres años calculados.

En la siguiente tabla se presenta la estimación de los principales gastos in-curridos al implementar el CRM. Observe que el gasto más importante seda en el primer año, que es el más intensivo en el desarrollo del producto.En los años subsecuentes, los desarrollos están limitados a actualizaciones yaumento de funcionalidades.

Costos (Millones USD) Año 1 Año 2 Año 3Licencias $ 1.00 $ 1.00 $ 1.00Desarrollo y TQM $ 2.50 $ 0.20 $ 0.20Mantenimiento $ 0.70 $ 0.20 $ 0.20

TOTAL: $ 4.20 $ 1.40 $ 1.40

Los costos totales para el proyecto durante los tres años, se estiman en $4.20+$1.40 + $1.40 = $ 7.00. Con una inversión de $ 7 MUSD se espera un bene-ficio de $ 32.10.

Los retornos de inversión para el primer año, para el tiempo de vida del pro-yecto, y el anual estimado, son los siguientes:

ROI primer año =6.8− 4.2

4.2× 100 % = 62 %

ROI tres años =32.1− 7

7× 100 % = 358 %

ROI anualizado = (1 + 3.58)1/3 − 1 = 66 %

El Periodo de recuperación (PBP) es el tiempo en que se recupera la inversión. Conmucha frecuencia se suele considerar únicamente la inversión inicial (el CAPEX), perodebe tomarse en cuenta que se hacen inversiones a lo largo del tiempo de vida del proyec-to, por lo que el cálculo del PBP debe considerarse en ese horizonte de tiempo.

Para el ejemplo anterior, el periodo de recuperación es:

PBP =costo total

beneficio en el tiempo=

732.136

≈ 7.8 meses

Como se ha comentado, en el despliegue de redes de comunicaciones, las inversionesiniciales pueden ser muy considerables, por lo que no es de extrañar que el PBP sea muygrande, mayor a siete años.

Regresando al ROI, una de sus complicaciones es determinar si la erogación que sehace es un gasto o una inversión, y, de hecho, en ocasiones ésto se depende de las políticasfiscales del país.

Diseño y Arquitectura de Redes Telemáticas 171

Page 182: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

En el ejemplo anterior, los costos que se tomaron en cuenta son costos de operacióny se consideran un gasto. En el siguiente ejemplo, el costo que se tomará en cuenta esel adquisición de un equipo, que en estricto sentido, debe depreciarse anualmente. Sinembargo, para enfatizar la complejidad en el cálculo del ROI, se considera que este equipoes un activo (como la compra de un edificio, o una inversión bancaria), por lo que su"valor"puede ser recuperado con la reventa del equipo.

EJEMPLO 7.3. Una empresa está considerando adquirir un dispositivo SD-WAN (Software defined WAN) que le permitirá optimizar sus enlaces WANal consolidar el tráfico de voz y datos y redistribuir el tráfico entre distintosenlaces para optimizar el balanceo de cargas.

Este ejemplo tiene enfatiza dos características frecuentes en el cálculo delROI: (1) Los beneficios se derivan al comparar el modo actual de operación(PMO, Present Mode of Operation), y (2) casos en que los "gastos"puedenser considerados inversiones en activos.

Los costos de la red WAN en el modo actual de operación se presentan en lasiguiente tabla:

Costos (Miles USD) Año 1 Año 2 Año 3Enlaces WAN $ 1,000 $ 1,100 $ 1,250Recursos humanos $ 200 $ 200 $ 250

TOTAL: $ 1,200 $ 1,300 $ 1,500Total acumulado: $ 1,200 $ 2,500 $ 4,000

Los costos de la red WAN con el equipo SD-WAN son los siguientes:

Costos (Miles USD) Año 1 Año 2 Año 3Enlaces WAN $ 750 $ 775 $ 825Recursos humanos $ 200 $ 200 $ 250Equipo SD-WAN $ 500

TOTAL: $ 1,450 $ 975 $ 1,075Total acumulado: $ 1,450 $ 2,425 $ 3,500

Estamos ahorrando $4, 000 − $3, 500 = $500. Para ello invertimos (y aúntenemos) $500, por lo que el retorno es:

ROI tres años =(500 + 500)− 500

500× 100 % = 100 %

ROI anualizado = (1 + 1)1/3 − 1 = 26 %

PBP =500100036

= 18 meses

Diseño y Arquitectura de Redes Telemáticas 172

Page 183: Diseño y Arquitectura de Redes Telemáticas

7.2. MÉTRICAS FINANCIERAS

Estas son algunas recomendaciones básicas relacionadas con el ROI:

Se debe crear lista de métricas (KPI) relacionadas con la estrategia del negocio,como atención a clientes; productividad y competitividad; eficiencia operativa. Sedebe evaluar cómo el proyecto impacta estas métricas, y eso requiere de expertos(no sesgados y no afectados por el proyecto) en las demás unidades de negocio.

Se debe desarrollar la metodología en términos financieros y con apoyo del área definanzas. Un análisis de ROI adecuado difícilmente uede salir del área de TI y detelecomunicaciones.

Se deben establecer beneficios que puedan ser claramente medibles (SMART). Losbeneficios “soft” deben verse como deseables, o bien, deben ser cuantificables (deforma convincente) por las áreas de negocio correspondientes

Se deben privilegiar proyectos en los que los beneficios se reflejen lo más prontoposible (con PBP corto); de lo contrario, se debe tomar en cuenta los gastos finan-cieros del dinero apalancado (los gastos de tesorería).

A pesar de su gran popularidad, el ROI tiene algunas limitaciones que deben tomarseen cuenta; entre las más importantes están:

No se toma en cuenta el costo del capital, lo cual puede ser muy delicado en pro-yectos con un PBP muy grande. Frecuentemente se calcula ROI ajustando a valorpresente neto. A esto se le conoce como RI-ROI (Risk adjusted ROI).

Al reportarse en porcentaje, no considera que los beneficios netos podrían ser muybajos para justificar la inversión. Por ejemplo, una inversión de $100,000 que generaun beneficio de 5,000 tiene un ROI de 5 %, mientras que una inversión con un ROIde 20 % puede ser una inversión $ 10 que genera un beneficio de $ 2.

De forma similar, el ROI oculta los flujos de capital requeridos. Específicamente,para grandes proyectos, los costos de inversión iniciales pueden ser tan altos, quehagan al proyecto inviable aún si el ROI parece atractivo.

7.2.3. Valor Presente Neto

El valor presente neto, NPV, es una medida del beneficio que genera una inversióndurante su vida útil considerando el valor del dinero. Se define como el valor presente delos ingresos futuros menos el valor presente del flujo de costos futuros.

En términos simples, podemos entender "valor presenteçonsiderando que un peso hoytiene y se percibe como más valioso que un peso en el futuro. Entre muchos otros factores,además de la pérdida de valor por inflación, se deben tomar en cuenta factores como elcosto de oportunidad, es decir, la incapacidad de tomar otras decisiones de inversión siese peso no se tiene disponible.

Diseño y Arquitectura de Redes Telemáticas 173

Page 184: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Para calcular el valor presente, se utiliza una tasa de descuento r que busca ser un in-dicador del riesgo financiero que la empresa atribuye a los factores anteriores. La fórmulade NPV es la siguiente:

NPV =T∑t=0

Ct

(1 + r)t,

donde t es el periodo en años, r es la tasa de descuento y Ct es el ingreso neto (esdecir, ingresos menos egresos) en el año t.

EJEMPLO 7.4. En la siguiente tabla se muestran dos opciones para invertir $1,000,000. La primera es para un proyecto a cinco años con ingresos netos de$500,000 cada año. La segunda es para un proyecto a tres años con ingresosnetos variables.

Opción 1 Opción 2Año Ingreso neto Ajustado Ingreso neto Ajustado

0 ($ 1,000,000) ($ 1,000,000) ($ 1,000,000) ($ 1,000,000)1 $ 500,000 $ 454,500 $ 1,000,000 $ 909,0002 $ 500,000 $ 413,000 $ 750,000 $ 619,5003 $ 500,000 $ 375,500 $ 500,000 $ 375,5004 $ 500,000 $ 341,5005 $ 500,000 $ 310,500

Total: $ 1,500,000 $ 895,000 $ 1,250,000 $ 904,000

En las columnas 2 y 4 se presentan los resultados netos de las dos opciones.Aparentemente la primer opción es más atractiva pues reporta un beneficioneto $250,000 mayor al de la segunda.

Sin embargo, al hacer el ajuste a valor presente con una tasa de descuento de10 %, la segunda opción es la más rentable.

Para poder determinar los ingresos netos anuales, se deben estimar los flujos de ca-pital. Para proyectos con fuertes inversiones iniciales como el despliegue de una red decomunicaciones, la curva de flujos de capital sería similar a la de la figura:

Diseño y Arquitectura de Redes Telemáticas 174

Page 185: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

En términos generales, los proyectos con NPV < 0 deben rechazarse y aquellos conNPV ≥ 0 deben analizarse más detenidamente.

Por otra parte, como debió quedar claro en el ejemplo, los resultados de NPV depen-den de la tasa de descuento utilizada. Es muy importante elegir un valor con objetividad yjustificarlo. No es raro encontrar tomadores de decisiones que estarán inclinados a definiruna tasa de descuento çonveniente".

Finalmente, todos los proyectos de largo plazo deben incluir un factor de riesgo adi-cional para tomar en consideración la manifestación de eventos ajenos al proyecto quepueden tener un gran impacto en el mismo. Por ejemplo, la aparición de nuevos juga-dores disruptores, factores macro-económicos, cambios en las prioridades del Estado yotros factores externos, pueden parecer improbables en el corto plazo, pero factibles enun escenario de 15 años.

7.3. Análisis tecno-económico

En otras secciones del curso se ha hablado sobre cientos de proyectos de redes WiFimunicipales desplegadas los Estados Unidos y en otros países en los últimos años. Cuandoestas redes se pensaron para ofrecer, además de servicios municipales, servicios públicosde acceso a Internet, la gran mayoría de estos proyectos fracasó, pero estas experienciasdejaron muchas lecciones que han contribuido a fortalecer las metodologías de diseño deredes.

Un ejemplo de estas lecciones es el marco propuesto por Mandviwalla (2008) para eldespliegue de redes inalámbricas municipales (WMN, Wireless Municipal Networks). Setrata de un marco compuesto por tres fases; si en alguna de ellas los elementos no estánclaramente definidos o si cuestiona la viabilidad de la red, el proyecto debería abandonar-se. El marco propuesto es el siguiente. Observe la gran semejanza de este marco con lametodología de diseño descendente que hemos seguido a lo largo del curso.

Diseño y Arquitectura de Redes Telemáticas 175

Page 186: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Fase 1 Objetivos . Los objetivos de la red deben ser claramente identificados. Para redesWSN éstos pueden ser disminuir la brecha digital, ofrecer mejores serviciosmunicipales, reducir los costos de operación de redes actuales, incrementar laatractividad de la región, empoderar a los ciudadanos, etcétera.

Actores clave . Los objetivos deben estar asociados a cubrir las necesidades deactores clave como ciudadanos, turistas, empleados de gobierno. Se debe con-siderar también quiénes se verían perjudicados (por ejemplo, competidorescomerciales, proyectos a los cuales se les recortaría presupuesto para finan-ciar la red).

Políticas y regulaciones . Es muy importante tomar en consideración las restric-ciones de política pública y regulatorias en el diseño de estas redes. En algu-nos casos, estas redes pueden ser vistas como competencia desleal. Para ello,la Unión Europea ha definido criterios en los que se fomenta el desplieguede redes públicas municipales (las llamadas zonas blancas) o en los que éstasse prohíben (las zonas negras). En esta fase también se analizan las implica-ciones legales sobre seguridad (si ésta es comprometida), niveles de servicio,atención a clientes, entre otros.

Fase 2 Servicios y aplicaciones . Con los resultados de la primera fase, se pueden definirlos servicios y aplicaciones que ofrecerá la red. Para ello deben priorizarse losobjetivos identificados,en función de los actores clave y de las restriccionesdetectadas.

Selección de tecnología . Ya se cuenta con todos los elementos necesarios paraproceder a un primer diseño, similar al diseño conceptual en la metodologíade diseño descendente. En esta etapa no se trata de la selección de tecnologíasespecíficas (lo que llamamos diseño físico) sino de consideraciones más gene-rales, como bandas de frecuencia para los servicios WiFi y para el backhaul,gateways para conexión a la red dorsal, infraestructura municipal disponiblepara desplegar la red, entre otros.

Finanzas y gestión . Esta etapa es crítica. Se debe tener un sólido estudio de fac-tibilidad económica no sólo para desplegar la red (el CAPEX) sino para ga-rantizar su operación (el OPEX) de forma sustentable. Se debe si los servi-cios ofrecidos son gratuitos (todos ellos, o sólo algunos), si la red puede serfinanciada con modelos publicitarios, o si los ahorros por el uso de nuevastecnologías son suficientes para desplegar la red.

En este capítulo conoceremos los conceptos básicos necesarios para realizareste tipo de análisis financiero.

Fase 3 . Si las etapas anteriores dan viabilidad al proyecto, se puede proceder al diseñodetallado (diseño lógico y físico) y al eventual despliegue de la red.

Diseño y Arquitectura de Redes Telemáticas 176

Page 187: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

7.3.1. Análisis de rentabilidad

Para evaluar la viabilidad financiera del proyecto, se debe hacer un análisis de renta-bilidad. La Unión Europea ha financiado varios proyectos marco (Titan, TONIC, EcoSys)de donde se derivan las principales líneas de esta sección. Para contextualizar el análisis,utilizaremos ejemplos del entorno mexicano.

Un análisis de rentabilidad tiene los siguientes pasos:

1. Se define el periodo de tiempo en el que el proyecto (la red a desplegar) estarávigente

2. Se realiza el análisis del mercado y la definición de los servicios a ofrecer. Estosdos pasos permiten hacer una estimación de la demanda

3. Se analizan los aspectos relacionados con el despliegue y operación de la red (laestimación de la oferta), tales como:

Características tecnológicas de la red

Estimación de costos: De adquisición, operación, mantenimiento, licencia-miento, etcétera

4. Se determinan los parámetros financieros del entorno en el que se desplegará la red,tales como tasas de interés, tasa de descuento, políticas fiscales para depreciacióny valoración de activos, impuestos a pagar, estímulos fiscales, etcétera Se hace elanálisis de los resultados financieros, como los análisis de sensibilidad y de riesgofinanciero

Consideraciones de Riesgos Como se ha mencionado en múltiples ocasiones, los pro-yectos de despliegue de redes de comunicaciones requieren de grandes inversiones y seespera que duren muchos años. En ambos casos, se entra en zonas de incertidumbre nodespreciable para elementos clave del proyecto.

En ejemplo, es la capacidad de estimar la demanda de servicios y de anchos de bandarequeridos en el corto, mediano y largo plazo. A principios del siglo XXI, arrastradospor la burbuja de las startups "dot com", muchos de los grandes operadores de telecomu-nicaciones tuvieron pérdidas millonarias al ser excesivamente optimistas en la demandaesperada de servicios y desplegar redes sobre-dimensionadas, con capacidades que senci-llamente excedían por mucho las necesidades de sus clientes. En cambio, con la apariciónde las tabletas y los teléfonos inteligentes, muchas redes celulares se vieron en la necesi-dad de hacer inversiones no planeadas, para poder crecer la capacidad de sus redes.

En proyectos de largo plazo tampoco es posible estimar con precisión las dinámicasde competencia entre operadores, la aparición de nuevos jugadores y modelos de negocio,como tampoco se puede estimar cómo evolucionará la tecnología y los costos asociadosa ella.

Diseño y Arquitectura de Redes Telemáticas 177

Page 188: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Para protegerse en cierta medida de estas fuentes de incertidumbre, es común agregaral análisis de valor presente neto, un factor de riesgo o risk penalty que va de cero (paraorganizaciones aversas al riesgo) a uno (para organizaciones que son tomadoras de riesgo.

En el análisis de riesgos se suele considerar distintos escenarios, que se interpretancomo posibles rutas de evolución de aspectos relevantes del proyecto. Éstos se presen-tan frecuentemente como tres rutas: El escenario tendencial, el cual considera que lascondiciones actuales no cambiarán sustancialmente; el pesimista, en el que varios de losriesgos se materializan (por ejemplo, que en las comunidades rurales se acentúen los fe-nómenos de migración); y el optimista, en el que los factores clave del proyecto (como lapenetración de mercado) evolucionan favorablemente.

El diseño de escenarios deberá incluir al menos los cuatro elementos que se muestrana continuación:

Regulatorio . Entorno que favorezca las condiciones de competencia, de fomento a lacompetencia y de protección a inversionistas: Número de competidores en los mer-cados de redes y servicios; participación de mercado de cada uno (índice HHI).

Ambiente . Densidad de clientes potenciales en el área de cobertura; nivel socio-económico;porcentaje de ingresos dedicado a telecomunicaciones; espacios disponibles paradespliegue de infraestructura; costos de arrendamiento, trámite de permisos, obracivil

Servicios . Tipo de servicios demandados y potencialemnte demandados; tasas de pene-tración; niveles de alfabetización digital; tarifas de suscripción; modelos de negocio

Tecnologías . Tecnologías disponibles; rutas esperadas de evolución tecnológica; costode equipos de telecomunicaciones; de soporte y de usuario final; costos OA&M

de mercado

Un elemento esencial en los estudios de rentabilidad. Por supuesto, se debe identificarcon la mayor precisión posible a qué población va dirigido el producto o servicio que seestá deseando introducir al mercado.

En redes de comunicaciones, podemos identificar varios segmentos de mercado connecesidades y patrones de consumo diferenciados. Tres segmentos típicos son:

El mercado residencial. Más orientado a consumo de contenidos, y por tanto, justifica laprovisión de redes de acceso con velocidades asimétricas. Los periodos de máximoconsumo en el sector residencial son de 19:00 a 22:00 horas.

El mercado corporativo. Es un mercado en el que las aplicaciones de misión críticapueden depender de la disponibilidad de la red, por lo la red debe garantizar nivelesde servicio (SLA) rigurosos. En este mercado también suele requerirse de un altonivel de privacidad y seguridad, así como de tecnologías avanzadas, como VPNs yenlaces MPLS.

Diseño y Arquitectura de Redes Telemáticas 178

Page 189: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

Pequeña y mediana empresa. Es un mercado que también demandará niveles de ser-vicio y funcionalidades de red avanzadas, pero no tan rigurosas como las de losmercados corporativos. En cambio, es un mercado mucho mayor que el corporati-vo.

Habiendo identificado los segmentos de mercado, deberá definirse su volumen. Parauna zona de cobertura determinada, cuántos hogares habrá, cuántas unidades productivaspequeñas y medianas? es una zona donde existe alta densidad de corporativos? No bastacon responder a estas preguntas con los datos presentes; en la medida de lo posible, sedebe analizar el crecimiento (o decrecimiento) esperado, pues lo que se busca es estimarel número potencial de suscriptores a lo largo del tiempo de vida del proyecto.

Estas cifras son las que definen las características demográficas de la región y distin-tos países las clasifican de distintas maneras. Por ejemplo, en Australia, un área urbana esaquella que tiene más de 200 habitantes por kilómetro cuadrado, mientras que en Canadá,el término se aplica para localidades con más de 400 habitantes por kilómetro cuadra-do. Se trata de dos países con territorios muy grandes y con una densidad de poblaciónrelativamente baja.

EJEMPLO 7.5. En México, la clasificación oficial y el porcentaje de pobla-ción en cada categoría de acuerdo al censo 2008 del Instituto Nacional deGeografía y Estadística es la siguiente:

Habitantes/km2 PorcentajeAlta densidad 12,000 26.4 %Densa 6,000 21 %Urbana 1,000 7 %Suburbana 250 1.9 %Semi rural 125 13.7 %Rural 30 8.2 %Aislada 12 17.7 %

La Ciudad de México, con 5, 800 hab/km2, es considerada en su conjuntocomo zona densa, pero si se eliminan las Alcaldías de Xochimilco y MilpaAlta, se trata de una zona de alta densidad.

Además de los datos demográficos, el estudio de mercado debe contemplar el nivelsocio-económico de los segmentos de mercado pues esto ayuda a determinar la capacidadde compra de los suscriptores, el tipo de servicios que potencialmente estarían demandan-do, las características de los equipos terminales que debieran ofrecerse, etcétera.

EJEMPLO 7.6. Potencial de mercado en México

Diseño y Arquitectura de Redes Telemáticas 179

Page 190: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

De acuerdo a la encuesta ENDUTIH 2017, en México había 71.3 mi-llones de usuarios de Internet pero muchos de ellos no son usuariosregulares. Más importante aún, se tenían al menos 40.4 millones de ciu-dadanos sin acceso a Internet.En Estados como Baja California, Sonora y la Ciudad de México, elporcentaje de usuarios de internet rebasa el 77 %, pero en Guerrero,Oaxaca y Chiapas, el porcentaje es menor a 50 %. A nivel nacional,sólo el 39 % de la pobalción rural tiene acceso a Internet.Por nivel socio-económico, 78 % del quartil más alto accede a Internet;el porcentaje baja a 34 % en el quartil más bajo de la poblaciónEl porcentaje de hogares con acceso a Internet en zonas urbanas eraligeramente inferior al 50 %, pero zonas rurales no llegaba al 10 %, loque nos coloca muy por debajo de países como Uruguay, Costa Rica yChile en América Latina.De acuerdo a México Evalúa, sólo el 26 % de las escuelas tenía accesoa Internet en ese año.

Es una priodidad de la Administración actual abatir estas brechas de acceso(y uso, y apropiación) a Internet.

Sin embargo, la demanda depende de la capacidad para poder pagar los servi-cios de telecomunicaciones. En 2006, el gasto promedio por hogar en servi-cios de TIC en los países de la OCDE, era de 2.3 % de sus ingresos, mientrasque en México oscilaba entre el 3 % y el 6 %.

Martin Hilbert, un investigador muy reconocido en temas de brecha digital,considera que el umbral en el que las TIC transitan de ser un bien necesario aun bien de lujo, es de 10 USD por persona por mes. Con estas cifras, más de15 millones de mexicanos jamás podrán acceder a Internet.

Otro elemento a considerar en el análisis de mercado, son las tasas de adopción tec-nológica, pues ellas ayudan a tener un referente de los flujos de ingresos esperados, y delos puntos donde el mercado puede empezar a presentar condiciones de saturación. Enla siguiente ilustración, la imagen de la izquierda muestra la típica curva "S"de absor-ción tecnológica y, a manera de ejemplo, la curva de la derecha muestra la penetración deInternet en los hogares mexicanos según INEGI.

Diseño y Arquitectura de Redes Telemáticas 180

Page 191: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

Se puede concluir que en México todavía hay un alto potencial de crecimiento... si lascondiciones económicas lo permiten.

La forma S de absorción tecnológica se basa en una teoría muy aceptada propuestapor Everett Rogers en 1962 (y actualizada en 2003). Si se acepta esta forma de difusiónpara analizar la penetración de la red a desplegar, también se debe aceptar el riesgo de queuna nueva tecnología surja y desplace a la anterior antes de que alcance una masa crítica.Es una tímida referencia a la teoría de las destrucciones creativas de Joseph Schumpeter.

Tratándose de un despliegue de red, al hacer el análisis demográfico también es con-veniente incluir información relacionada con las características geográficas de la zonaa atender. Ya se ha comentado en varias ocasiones que una región con una orografíamuy accidentada, con zonas boscosas presentará retos de despliegue distintos a los quese presentan en un valle. Las zonas urbanas densas son particularmente complejas porla dificultad para desplegar infraestructura subterránea (para medios cableados) y por lapésima propagación de señales electromagnéticas en calles angostas con edificios altos(para medios inalámbricos).

Por otro lado, el análisis de mercado debe incluir un análisis de la competencia. Comomínimo, debe identificarse el número, su participación de mercado, cuáles son sus estra-tegias y fuentes de ventaja competitiva, si existen o pueden imponer barreras de entrada ysi el contexto regulatorio permite establecer alianzas de competencia y cooperación entreellos.

Al analizar el mercado de competencia en telecomunicaciones, se debe tomar en con-sideración que este sector presenta características similares a las de un Monopolio Na-tural. A excepción de algunos mercados en tecnologías de acceso altamente competidas,es muy frecuente encontrar un número muy pequeño (entre tres y cinco) de operadoresestablecidos.

Por último, dado que en México como en muchos otros países el acceso a Internet seha admitido como un Derecho Humano (de tercera generación), también debe contemplar,junto con el análisis de escenarios, modelos de incentivos, financiamiento alterno, u otrotipo de apoyos que contribuyan a reducir las barreras de entrada para el despliegue deinfraestructura. Algunas estrategias que han probado su éxito en distintas latitudes son:

Facilidades de acceso a infraestructura . La participación del Gobierno para fomentarel despliegue de infraestructura de red y promover su adopción puede darse endiversos ámbitos. Los acuerdos de compartición (que en México son obligatorios)pueden ayudar a reducir drásticamente los costos de despliegue, sobre todo en áreasrurales. En algunos países de Escandinavia se ha fomentado hasta la comparticiónde distintos elementos de la red.

En México también se contempla que todos los edificios públicos que puedan ha-cerlo, se pondrán a disposición para montar sobre ellos infraestructura de teleco-municaciones. Por desgracia, esta iniciativa sólo es aplicable en el ámbito federal,mientras que los mayores retos para el despliegue de infraestructura se dan a nivelmunicipal.

Diseño y Arquitectura de Redes Telemáticas 181

Page 192: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

También está en manos del Estado el garantizar la disponibilidad de espectro paraservicios de telecomunicaciones, así como el de facilitar los derechos de vía para eldespliegue de infraestructura cableada.

Mercado competitivo . Uno de los factores más importantes al analizar la competitivi-dad de un país, es la fortaleza y estabilidad de sus instituciones. En este caso, losmarcos regulatorios deben contribuir a garantizar que los operadores de redes pue-den prestar sus servicios en condiciones de un mercado estable y equilibrado. Esaes la función principal del Instituto Federal de Telecomunicaciones. Así mismo, lasinstituciones legislativas y judiciales deben contribuir a asegurar la estabilidad delas grandes inversiones que se hagan en el país.

Mitigación de riesgos financieros . Como se ha comentado, el despliegue de redes detelecomunicaciones de gran escala, conlleva fuertes inversiones en largos periodosde tiempo. Existen varias formas de mitigar los riesgos inherentes a este tipo deinversiones, como lo son las Asociaciones Público-Privadas (APP), que es la figuracon la que se ha desplegado la Red Compartida en nuestro país, el acceder a finan-ciamiento a través de las Bancas de Desarrollo nacionales o internacionales -sobretodo para proyectos de impacto social-, y el flexibilizar los modelos de concesiona-miento y el pago de contraprestaciones.

Definición de servicios

Una vez identificados los segmentos de mercado relevantes para el proyecto, se debendefinir los servicios y las características para su aprovisionamiento en función del perfilde suscriptores en cada segmento.

Esta es una tarea sumamente compleja pues en los últimos diez años los patrones deconsumo de tráfico han cambiado radicalmente en todo el mundo tanto a nivel empresarialcomo en el segmento residencial.

En 2007 se estimaban velocidades de acceso de 1 Mb/s para servicios residenciales y 2Mb/s para el segmento PyME, con tasas de crecimiento de 20 % anual. En ambos sectores,pero sobre todo en el segmento residencial, estas cifras han cambiado sustancialmente.

Este cambio se explica por el surgimiento de nuevos dispositivos, una creciente tran-sición a la provisión de servicios en la nube, nuevos modelos de negocio y nuevas formasde interacción en los llamados ecosistemas digitales.

Diseño y Arquitectura de Redes Telemáticas 182

Page 193: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

Por ejemplo, la figura a la derechamuestra cómo ha evolucionado eltipo de dispositivos en el hogar querequieren de servicios de acceso aInternet. La gráfica está tomada deun estudio reciente hecho por Of-com, el regulador de telecomunica-ciones del Reino Unido.En México, como en la mayoríade los países latinoamericanos másavanzados, suele observarse una pe-netración tecnológica similar concinco años de desfase y con picos deabsorción un poco más atenuados.

EJEMPLO 7.7. La consultora Pyramid Research estimó en 2009 el poten-cial de servicios demandados para México hasta 2014 como se muestra en lafigura siguiente. La realidad fue muy distinta a lo proyectado por los especia-listas.

La demanda de ancho de banda ha crecido sustancialmente debido a la creciente im-portancia en el consumo de contenido de video. De acuerdo a estimaciones de Cisco, en2017 el 70 % del tráfico en Internet era video.

Diseño y Arquitectura de Redes Telemáticas 183

Page 194: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

La consultora WIK Consult toma algunos de estos datos y proyecta la estimación deancho de banda de varios servicios para 2025. Los resultados se presentan en la siguientetabla. Llama la atención el crecimiento de video (consistente con las estimaciones deCisco) así como de consumo de juegos y e-servicios.

2015 Bajada CAGR 2025 Bajada 2025 Subida Pérdida Latencia(Mb/s) estimado (en %) (Mb/s) Mb/s de paquetes

Internet básico 2 25 ≈ 20 ≈ 16 o oHomeoffice VPN 16 30 ≈ 250 ≈ 250 + +Cloud computing 16 30 ≈ 250 ≈ 250 + ++Video 4K, 3D, HD 14 20 ≈ 90 ≈ 20 ++ +Video 8K, VR 25 30 ≈ 300 ≈ 60 ++ +Comunicaciones 1.5 20 ≈ 8 ≈ 8 ++ +Videocomunicaciones 8 15 ≈ 25 ≈ 25 ++ ++Juegos 25 30 ≈ 300 ≈ 150 ++ ++e-Salud 2.5 30 ≈ 50 ≈ 50 ++ +e-Hogar 2.5 30 ≈ 50 ≈ 50 o oOffloading 2 30 ≈ 15 ≈ 12 o o

Por supuesto, el despliegue de estos servicios depende en gran medida de que las tec-nologías para soportar este consumo estén listas y de que los suscriptores estén dispuestosa pagar por las capacidades ofertadas.

El mismo estudio de WIK Consult presenta varios escenarios de absorción en loshogares del Reino Unido. En la siguiente tabla se muestran dos de ellos: A la izquierda, unescenario optimista con un pronóstico de alto consumo de ancho de banda, y a la derecha,uno un poco más conservador donde no se despliega masivamente el uso de contenidos 8Kni realidad virtual (excepto para videojuegos). Aún en el escenario conservador, se prevéque más del 50 % de los hogares demandarán velocidades descendentes de al menos 300Mb/s y 8 % estarán preparados a contratar servicios de 1 Gb/s.

Estimación del porcentaje de demanda de ancho de banda en hogares en el ReinoUnido en 2025.

Demanda Escenario Escenariooptimista conservador

Muy alta (> 1Gb/s ↓ , 600Mb/s ↑ ) 40 % 20 %Alta (300Mb/s− 1Gb/s ↓, 300Mb/s− 600Mb/s ↑) 42 % 56 %Baja (< 300Mb/s ↓, < 300Mb/s ↑) 10 % 15 %Sin banda ancha 7 % 7 %

Para el segmento empresarial, sobre todo para el corporativo, la calidad de serviciodebe ser una prioridad en el diseño de la red. En los acuerdos de nivel de servicio debenespecificarse las características técnicas que el servicio debe cumplir.

Para este segmento el factor de sobre-suscripción es nulo o muy bajo. El servicio aPyMEs puede ser más tolerante con el fin de reducir los costos de servicio. En el segmento

Diseño y Arquitectura de Redes Telemáticas 184

Page 195: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

residencial, sobre todo cuando la provisión de servicios se hace a través de cable, la sobre-suscripción suele alcanzar valores de 10 a 30.

Finalmente, se debe tener una estimación de las tarifas a las que se pueden ofertar losservicios, pues esto determina los flujos de ingresos de la red. Es un ejercicio particular-mente complejo pues los costos de servicios de telecomunicaciones han venido a la bajaen los últimos años. Al mismo tiempo, los usuarios van demandando más capacidad y ma-yor calidad de las redes. Aunque este aumento en la demanda tienda a empujar el ARPUAverage Revenue per User a la alza, la realidad es que en la mayoría de los países desa-rrollados, la presión competitiva ha sido dominante y las empresas de telecomunicacioneshan visto una caída neta en su ARPU.

Esto ha hecho que las empresas diversifiquen su oferta de servicios o que modifiquensus modelos de negocio para mantener su rentabilidad. Un ejemplo de estas modificacio-nes es que son cada vez menos las empresas que absorben el costo del equipo terminalpara ofrecerlo en arrendamiento a sus abonados.

7.3.2. Despliegue y operación de la red

A grandes rasgos, se puede decir que el análisis del mercado y de los servicios per-mite tener una estimación de los ingresos directos que tendrá la red. Para el análisis defactibilidad financiera, será necesario analizar los costos de adquisición, operación e im-plementación de la red.

Por supuesto, estos costos dependen de las tecnologías, de la escala, las condiciones decobertura, y de casi todo lo que se ha mencionado en este capítulo. A manera de ejemplodeberán tomarse en consideración, entre muchos otros factores:

Las bandas de frecuencia asignada . El primer punto debe ser el análisis del costo porhertz, el tamaño del bloque asignado y la negociación para pagar los derechos deuso de ese bloque. Pero este es sólo uno de muchos otros factores. Por ejemplo, esmuy probable que el bloque se encuentre rigurosamente acotado tanto en frecuenciacomo en área de cobertura. En este caso, se debe incluir equipo adicional paragestión de interferencia, control de potencia y monitoreo de ancho de banda.

Componentes . Se deben incluir todos los componentes que conforman la red: Estacio-nes base, elementos para las redes de acceso, backhaul y red dorsal, equipo en laspremisas del cliente CPE, Customer Premises Equipment y sus posibles costos deinstalación, etcétera. Este análisis debe hacerse con todo detalle, aunque para finesdidácticos en esta sección únicamente se consideran los componentes principales.

Elementos de servicio. Aquí se incluyen todos los gastos indirectos relacionados con laprovisión de servicios de la red, casi todos vinculados con los costos de operación.Elementos como marketing, ventas, OA&M, arrendamiento de sitios, licenciamien-to de software, equipos y espectro(de ser el caso), costos de interconexión, entreotros.

Diseño y Arquitectura de Redes Telemáticas 185

Page 196: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Dado que los despliegues de red responden a estimaciones de penetración y al ca-lendario establecido en el plan maestro, las tasas reales de penetración deben serestimadas para poder planificar los gastos de implementación y la evolución de losgastos de servicio

En esta sección se utilizará como hilo conductor el despliegue de una red WiMAXIEEE 802.16 para ofrecer servicios de acceso a Internet. Está fuertemente inspirado enlos trabajos de Smura et al. (2008)3.

Antes de entrar en el ejemplo, conviene recordar que una red se diseña con base en lacobertura deseada, en la capacidad requerida o en una combinación de ambas.

El bloque de frecuencias asignadas a un operador móvil suele dividirse en sectores.La capacidad (en b/s) de un sector depende de:

El ancho de banda disponible, es decir, del tamaño del bloque del sector

Las bandas de frecuencia, pues unas frecuencias son más susceptibles a interferen-cias que otras

La eficiencia de la modulación espectral, es decir, de la cantidad de bits que puedeninyectarse en cada baudio

Las condiciones ambientales, tanto por las interferencias generadas por objetos co-mo bosques y edificios, como -en nuestro caso- por el hecho de que el equipo ter-minal (o su antena) se encuentren en el interior o en el exterior de edificios y si setiene o no línea de vista con la radio base.

Los protocolos de red. Como sabemos, las dinámicas de los protocolos de comuni-caciones en las capas superiores, pueden afectar drásticamente la capacidad real dela red.

Sin entrar en detalles técnicos, si en 2011 se estimaba que una celda debía ofrecer1 Mb/s por km2 y, como se ha mencionado en la sección anterior, la tendencia esperadaes de 100 a 1000 Mbps/km2, el radio medio de una celda 3G/HSDPA debería ser de unos500 metros; los despliegues de redes celulares están transitando de macro a micro-celdas.

En las redes IEEE 802.16 cada equipo receptor (cada CPE) puede elegir su propioesquema de modulación. A mayor distancia, tiende a usarse un modulador más robusto,como se muestra en la siguiente figura.

3T. Smura, H. Hämmäinen, T. Rokkas and D. Katsianis, Technoeconomic analysis of fixed WiMAX net-work deployments, in Mobile WiMAX – Toward Broadband Wireless Metropolitan Area Networks, NewYork: Auerbach Publications, 2008.

Diseño y Arquitectura de Redes Telemáticas 186

Page 197: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

La figura se obtiene para un sector de 7 MHz en la banda de frecuencia de 3.5 GHz.También muestra cómo la capacidad del sector disminuye con las condiciones del entorno:Los despliegues en el exterior tienen mayor que capacidad que aquéllos con el CPE enel interior y los despliegues urbanos, en esa banda de frecuencia, tienen una degradaciónmucho mayor que los despliegues suburbanos.

En un entorno urbano con CPEs en el interior de los hogares, si la radio base está a750 metros se distancia, se podrá ofrecer una velocidad de 10 Mbps con un Códec BPSK;sólo podrá ofrecer la velocidad máxima de 25 Mbps en aproximadamente el 40 % del áreade cobertura.

La siguiente tabla las coberturas máximas en kilómetros para WiMAX con bloques de7 MHz en dos bandas de frecuencia distintas para ambientes donde el CPE se encuentraen el exterior, en el interior y en el exterior, puede tener línea de vista (LOS) hacia la radiobase, o no tenerla (NLOS).

Zona Urbano Suburbano RuralBanda 2.5 GHz 3.5 GHz 2.5 GHz 3.5 GHz 2.5 GHz 3.5 GHz

NLOS CPE interior 0.83 0.7 1.02 0.85 – –NLOS CPE exterior 2.40 2.00 3.25 2.70 – –LOS CPE exterior – – – – 12.0 10.0

En el estudio, el único escenario en el que se conside-ran enlaces con línea de vista, es un despliegue ruralen el que se ponen pequeñas antenas rectangulares,como la de la figura de la derecha, en las azoteas o enlos balcones de los hogares.Una arquitectura similar se utilizó en México paraofrecer servicios de telefonía y datos en zonas rura-les en la banda de 450 MHz a través del Fondo deCobertura Social.En la siguiente figura se muestra una arquitectura muy general de una red WiMAX.

Diseño y Arquitectura de Redes Telemáticas 187

Page 198: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

De estos componentes, sólo se tomarán en consideración los relacionados con la redinalámbrica para el análisis de costos, y casi exclusivamente tomaremos costos de adqui-sición y, para estimación de Impex, se mencionan los porcentajes de reducción de costosen algunos equipos.

En la tabla siguiente los costos promedio de los componentes para una red WiMAX a3.5 GHz con seis sectores por radio base. Los precios presentados son los costos promediode esos equipos en Europa en 2006. El despliegue se hizo en un país nórdico y el CPE eraadquirido por el operador y arrendado al cliente.

Elemento Precio (2006, USD) Caída anualen precio estimada

Estación base (BS) $ 10,000 15 %Sector estación base $ 7,000 15 %Instalación BS $ 5,000 + $ 500 por sectorRenta anual sitio BS $ 1,800 + $ 1,200 por sectorEquipos backhaul $ 20,000 por BS 10 %Renta anual enlaces backhaul $ 2,400 por BSCPE interior $ 250 20 %CPE exterior $ 350 20 %Instalación CPE exterior $ 100OAM 15 % de CAPEX

Aunque el CPE en exterior es mucho más caro que el CPE en interiores ($100 USDdel equipo más $100 USD de la instalación), se necesitarían menos radio bases para des-pliegues iniciales, sobre todo en entornos rurales y suburbanos, como se mostrará másadelante.

Diseño y Arquitectura de Redes Telemáticas 188

Page 199: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

Como referencia muy imprecisa porque se trata de redes con características distintas,en la siguiente tabla se presentan los costos estimados por Del Villar (2009) para undespliegue de una red WiMAX en la banda de 2.5 GHz en México.

Elemento Precio (2009, USD) Caída anualen precio estimada

Adaptación de sitios existentes $ 20,000Adquisición de nuevos sitios $ 90,000Adquisición backhaul E1/T1 $ 1,000Adquisición backhaul DS3 $ 4,800Adquisición backhaul inalámbrico (45 Mb/s) $ 15,000Estación base (BS) $ 35,000 5 %Sector estación base $ 15,000 5 %Renta anual enlaces backhaul $ 1,000 a $2,500 5 %Renta anual sitio BS $ 8,400Marketing $ 46,000OA&M backhaul inalámbrico 6 % CAPEX

A pesar de que se trata de redes con muchas diferencias (en particular, las fechas delestudio, las bandas de frecuencia y las tecnologías y topologías del backhaul, que no seincluyen en el estudio) se muestran en azul algunos puntos que conviene resaltar.

En primer lugar, los costos de la estación base, de los sectores y los descuentos anualesesperado son muy distintos en el estudio de Smura para un país nórdico, y el de Del Villarpara México. Desgraciadamente, la causa principal de estas diferencias se explica porqueen la región nórdica se genera la tecnología, mientras que en América Latina ésta seadquiere y se consume.

Con relación a los costos de arrendamiento de los sitios, son dos las causas principa-les de las diferencias. En primer lugar, el estudio de Smura contempla mayoritariamentedespliegues suburbanos y rurales, donde el costo de la propiedad es mucho menor. En se-gundo, y sobre todo, en el país nórdico la co-ubicación y compartición de infraestructuraera exigida por ley. En México, hoy se tiene la misma regulación, pero en la época delestudio de Del Villar, cada operador debía conseguir y arrendar sus propios sitios.

Finalmente, los costos de operación en México son notablemente más bajos que enel estudio de Smura (aunque solamente se están considerando los costos asociados albackhaul). Esto refleja la gran diferencia en salarios y costos de capital humano entre lospaíses de América Latina y los del norte de Europa.

Ha llegado el momento de integrar toda la información recabada a lo largo del estudio,para determinar cuántos componentes de red serán necesarios para su despliegue.

En la siguiente tabla se presentan tres de los escenarios analizados por Smura: Des-pliegues urbanos en la banda 3.5 GHz para zonas con densidades de población de 2,000,1,000 y 500 habitantes por km2. En todos los casos, se busca cubrir una población obje-

Diseño y Arquitectura de Redes Telemáticas 189

Page 200: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

tivo de 50,000 hogares. Para el bloque de frecuencias asignado, se estima que un sectorpuede ofrecer en promedio 15 Mb/s y que una radio base puede tener hasta seis sectores.

Escenario urbano. Banda 3.5 GHz. Población objetivo: 50,000 hogaresDensidad Tecnología Año 1 Año 2 Año 3 Año 4 Año 5

2,000No. de BS 3 5 8 11 15No. de sectores 18 30 40 62 90Modulación BPSK QPSK 16-QAM 16-QAM 16-QAM

1,000No. de BS 5 8 9 14 16No. de sectores 18 30 53 83 90Modulación BPSK QPSK QPSK QPSK 16-QAM

500No. de BS 10 10 14 16 20No. de sectores 30 44 79 83 120Modulación BPSK QPSK QPSK QPSK QPSK

La tabla muestra un escenario de penetración en el que se cubre el 100 % de la pobla-ción objetivo en cinco años. Aunque en el estudio no se menciona, se puede suponer quela tecnología desplegada se adapta a las necesidades crecientes de la población duranteese periodo de tiempo. Hay varios puntos a resaltar.

Se pueden observar las limitaciones de capacidad y ancho de banda. Sabemos quecon la banda de 3.5 GHz, la cobertura es baja. Por ello, en la región con la menordensidad de población (tercer escenario) se requiere de más estaciones base y mássectores.

Conforme el número de abonados va en aumento, se debe aumentar el número deradio bases (y por consiguiente, el número de sectores). Sin embargo, en el esce-nario de alta densidad (2000) el número de radio bases crece cinco veces, mientrasque en el de baja densidad (500) crece al doble. Esto se explica por el gran númerode radio bases que se tuvo que desplegar desde un inicio.

Con un número mayor de radio bases, la distancia media entre el CPE y la radiobase disminuye. Esto permite tener modulaciones con mayor densidad espectral.

Análisis financiero

De la sección anterior se obtiene el número de componentes estimados para desplegarla red conforme al plan maestro. También se identificaron los costos de equipos, arrenda-miento, licenciamiento y gastos de operación, entre otros.

Para llevar a cabo el análisis financiero, en esta etapa se requiere definir el valor de losprincipales parámetros financieros, como las tasas de interés, la tasa de descuento para elanálisis de valor presente, las tasas fiscales y de depreciación, etcétera.

El análisis financiero reportará algunas de las métricas que se presentaron al inicio deeste capítulo, como el costo total de propiedad, la tasa interna de retorno, y la utilidad avalor presente neto.

Diseño y Arquitectura de Redes Telemáticas 190

Page 201: Diseño y Arquitectura de Redes Telemáticas

7.3. ANÁLISIS TECNO-ECONÓMICO

Las siguientes gráficas presentan los flujos de capital a valor presente de los escenariosanalizados por Smura bajo los siguientes supuestos:

No se consideran costos administrativos ni pago de frecuencias ni gastos de inter-conexión

Los CPE son adquiridos por el operador y arrendado a los usuarios

Los ARPU mensuales considerados eran de 30 USD para el usuario residencial yde 200 USD para el comercial.

Se consideran dos bandas de frecuencia. Bandas a 2.5 GHz con bloques de 5.5 MHzy bandas a 3.5 GHZ con bloques de 7 MHz.

Urbano Suburbano RuralDensidad Banda NPV Densidad Banda NPV Densidad Banda NPV

(GHz) (Me) (GHz) (Me) (GHz) (Me)

2,0003.5 1.017

2003.5 0.664

203.5 4.887

2.5 0.956 2.5 0.808 2.5 4.307

1,0003.5 0.695

1003.5 -0.588

103.5 3.565

2.5 0.634 2.5 -0.236 2.5 3.658

5003.5 0.111

503.5 -3.298

53.5 2.213

2.5 0.174 2.5 -2.186 2.5 1.998

En áreas urbanas con mayor densidad poblacional, se tienen VPN claramente posi-tivos, aunque con densidades de 500 hogares por km2, la rentabilidad se empieza a veramenazada. Por la misma razón, en los escenarios suburbanos es limitadamente rentablesólo para áreas de 200 hogares por km2. En los demás casos, el ingreso esperado por losrelativamente pocos abonados, no cubre los gastos de despliegue a valor presente.

El análisis de las zonas rurales es de llamar la atención: En todos los casos el proyectotiene alta rentabilidad a valor presente y periodos de recuperación muy cortos. Lo queocurre es que a pesar de que hay muy poca población atendida, también se desplieganpocas celdas, pues éstas nunca se saturan.

En las áreas urbanas y rurales, los despliegues en la banda de 3.5 GHz con bloques de7 MHz resultan más rentables que los despliegues de 2.5 GHz con bloques de 5.5 MHz.Aunque esta última frecuencia tiene mayor cobertura, su capacidad más limitada requiereque se desplieguen más celdas. En el caso suburbano, hay una densidad menor y se puedeaprovechar mejor la cobertura de la banda a 2.5 GHz.

Diseño y Arquitectura de Redes Telemáticas 191

Page 202: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 7. ANÁLISIS TECNO-ECONÓMICO

Algunos de los supuestos en el análisis anterior son muy aventurados. No considerarcostos administrativos, pago de concesión de frecuencias o costos de interconexión, poneen grave riesgo la viabilidad del proyecto. En este ejercicio se omiten únicamente parasimplificar el ejemplo.

De manera similar, es aventurado suponer que en las comunidades rurales se puedetener el mismo ARPU que en los entornos urbanos, o que el CPE se pueda adquirir almayoreo a un determinado precio que se recuperará con su arrendamiento a los abonados.

Por estas razones, los análisis financieros deben incluir un análisis de sensibilidad.Este análisis consiste en seleccionar aquellas variables en las que el cambio en los valoressupuestos, pueden tener un fuerte impacto en el resultado del análisis.

Para el ejemplo que se ha estado analizando, las tres variables clave que fueron con-sideras son el ARPU, el costo del CPE (y su instalación, si es en exterior) y el costo delos elementos de la radio base (BS). En las siguientes gráficas se muestran los resultadospara tres de los escenarios analizados. En el extremo izquierdo se presenta el urbano a 3.5GHz con una densidad de 1,000 habitantes por km2; al centro el suburbano a 3.5 GHz con100 hab/km2 y a la derecha el rural a 3.5 GHz con 10 hab/km2.

Las líneas continuas sólidas corresponden las variaciones en el ARPU, las punteadasrojas a variaciones en el costo del CPE y las punteadas verdes a variaciones en el costo dela BS.

Para entender estas curvas, tomemos, por ejemplo, el escenario urbano con 1000 habi-tantes. En la tabla anterior se había estimado un VPN de 0.695 Meal cabo de cinco años.Ese es el punto en el que convergen las tres líneas con los supuestos de ARPU, CPE y BSconsiderados.

Si el ARPU disminuye, por ejemplo porque las condiciones de mercado hacen queno se pueda cobrar más que el 90 % del estimado original (es decir, una disminución del10 % en el ARPU), entonces el VPN llegaría prácticamente a cero. En cambio, si lograaumentar el ARPU a 20 % más de lo estimado, el VPN subiría hasta ≈ 1.4Me.

El análisis de sensibilidad nos dice que el ARPU es la variable que más influye en elanálisis de factibilidad financiera. Esto es particularmente cierto en el escenario rural puescon muy pocos usuarios, cualquier cambio en el costo de los servicios tendrá un fuerteimpacto en los ingresos de la empresa.

Diseño y Arquitectura de Redes Telemáticas 192

Page 203: Diseño y Arquitectura de Redes Telemáticas

Capítulo 8

Respuestas a problemas seleccionados

Metodología de diseño de redes

1.2

• Requerimientos incompletos

• Falta de involucramiento del usuario

• Falta de recursos

1.5Sí: Para el desarrollo de infraestructura, si hemos hecho un buen trabajo de prue-bas e integración en la fase de desarrollo, la estabilización de la solución puedeincorporarse a la fase de despliegue.

1.7Para evitar las principales causas de fracaso identificadas en los reportes CHAOS.Una visión clara y compartida ayuda a que todos los involucrados en el proyectoentiendan con precisión lo que se busca y lo que se obtendrá.

1.12No: No cumple con los objetivos SMART. No están definidos claramente en térmi-nos cuantitativos.

1.15

Gerente de programa. Es el arquitecto principal del proyecto y lo administra.Mantiene los compromisos adquiridos en el Plan Maestro y Calendario Maes-tro. Coordina y facilita la comunicación con los demás miembros del equipo.Gestiona y evalúa el plan de riesgos.

Gerente de producto. Interfaz con el cliente, es responsable de definir y mante-ner la visión conjunta del proyecto a través de la identificación de objetivosrealistas y su transformación en requerimientos específicos.

Page 204: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 8. RESPUESTAS A PROBLEMAS SELECCIONADOS

Desarrollo. Diseña la solución y dimensiona tiempos y recursos necesarios. Laimplementa o supervisa su implementación y prepara la etapa de despliegue.

Pruebas. Comprueba la correcta funcionalidad de la solución a través del diseño ypuesta en marcha del programa de evaluación.

Experiencia del usuario. O capacitación, administra los requerimientos del usua-rio, participa en la decisión al confrontar facilidad de uso contra rendimiento,capacita al usuario.

Administrador de liberaciones. Controla la logística para liberar y desplegar lasolución. Administra las operaciones de soporte y entrega.

1.20Mitigar el riesgo significa tomar las medidas necesarias para anularlo o al menospara minimizar que éste se manifieste.

El plan de contingencia consiste en definir las acciones a tomar si el riesgo se ma-nifiesta con el fin de minimizar su impacto.

Requerimientos técnicos

2.1Porque los modelos de trabajo, en particular en lo que se refiere al almacenamientoy difusión de información en las empresas, están cambiando. Por ejemplo, la de-cisión de centralizar los servidores (granjas de servidores) el acceso centralizadoa información de la compañía a través de servidores WWW en intranets provocanun enorme flujo de información entre la LAN departamental y la LAN donde seconcentran los servidores.

2.4

• Contar con un muy buen sistema de administración y monitoreo que permitadetectar anticipadamente fallos o condiciones potenciales de fallo en la red.

• Documentar los incidentes (fallos, causas y pasos para su reparación) y contarcon un sistema de mesa de ayuda que permita minimizar el tiempo de repara-ción y puesta en funcionamiento.

• Contar con equipos y enlaces redundantes y/o de respaldo para mantener lacontinuidad de operaciones.

2.8Se pierde dinero durante el tiempo de reparación, MTTR.Un año = 365× 24× 60 = 525, 600min

(a)

MTTR =525, 600× (1− 0.999)

0.999= 526.126min→ 526.126×$500.00 = $263, 063.00

Diseño y Arquitectura de Redes Telemáticas 194

Page 205: Diseño y Arquitectura de Redes Telemáticas

(b)MTTR = 52.56min→ 52.56× $500.00 = $26, 282.62

(c) La empresa puede tener hasta 60 min de caídas al año, por lo que la dispo-nibilidad de su red debe ser:

A =MTBF

MTBF + MTTR=

525, 540

525, 600= 99.988 %

2.13Ignorando todos los demás elementos, el throughput, (ζ), estará determinado por latasa a la que se pueden emitir ventanas. Esta tasa puede estar limitada por el retardode propagación o por la capacidad del enlace.

El retardo de propagación es:

4× 36, 000

300, 000= 0.48 s

En el primer caso, el retardo de transmisión es:

512× 8

64000= 64ms

En este caso, la latencia es el elemento determinante. El throughput es:

ζ =512× 8

0.48= 8533 b/s

En el segundo caso, el retardo de transmisión es:

15× 512× 8

64, 000= 0.960 s

Ahora, y en el tercer caso, la transmisión está limitada por la capacidad del enlace,por lo que ζ = 64 kb/s.

2.15

(a)Cada paquete çonsumeün espacio de: b = (1, 518 + 8 + 12)∗8 = 12, 304 bits.En una red FastEthernet (100Mb/s), se pueden enviar:

100Mb

12, 304b= 8, 127 p/s

(b)

8 127× 1, 518× 8

100M= 98.694 %

Diseño y Arquitectura de Redes Telemáticas 195

Page 206: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 8. RESPUESTAS A PROBLEMAS SELECCIONADOS

2.20

IPv4 IPv625ms 40ms 25ms 40ms

G.726(32 kb/s) 44.8 kb/s 40 kb/s 51.2 kb/s 44 kb/sG.723

(6.4 kb/s) 19.2 kb/s 14.4 kb/s 25.6 kb/s 18.4 kb/s

2.26(a) El retardo de propagación es de: 1,000 km

200,000 km/s= 5ms.

(b) Suponiendo que se transmiten ventanas completas, pueden enviarse 24 ×1, 024 × 8 = 196, 608 bits antes de recibir un acuse de recibo. El tiempo detransmisión es de:

196, 608bits

622Mb/s= 309µs;

La red está limitada en latencia.

(c) Se necesita un tiempo de ida y vuelta (RTT) para recibir el acuse de reciboy poder enviar otra ventana. Por consiguiente, el throughput máximo es:

196, 608 bits

0.01 s= 19.7Mb/s

(d) La eficiencia es:19.7Mb/s

622Mb/s= 3.16 %

Caracterización de la red

3.1El baselining permite obtener un punto de referencia contra el cual evaluar el desem-peño de la red propuesta. Además permite identificar problemas con la red actual.Básicamente consiste en evaluar el desempeño de la red actual y se realiza mediantelas herramientas apropiadas de colección de información (monitores, analizadores,herramientas de administración, etc.). Las principales dificultades para este tipo deestudio son la definición de un período y frecuencia de recolección apropiados.

3.7La congestión es una degradación en el rendimiento debido a un exceso de paquetesen la red o en un segmento de ésta. Para contenerla, se pueden usar mecanismoscomo:

a) de lazo abierto. La fuente es responsable de no emitir más paquetes que losconvenidos con el proveedor a fin de que el dimensionamiento estimado cum-pla con lo previsto (traffic engineering). Mecanismos típicos para conformarel tráfico a lo convenido son Leaky bucket y Token bucket.

Diseño y Arquitectura de Redes Telemáticas 196

Page 207: Diseño y Arquitectura de Redes Telemáticas

b) de lazo cerrado en los extremos. El extremo receptor monitorea la calidad dela información recibida (p.e. pérdidas de paquetes) y notifica a la fuente. Si sedetectan pérdidas, la fuente reduce su tasa de transmisión. Ejemplos: controlde congestión en TCP; mecanismo RTP/RTCP.

c) reactivo en los nodos de conmutación. Al detectar congestión, los nodos en-vían notificaciones a los puntos extremos. Ejemplos: FECN, BECN en FrameRelay; mensajes Source Quench, mecanismo ECN en TCP/IP.

3.9El control de congestión de TCP se basa en un mecanismo de ventanas deslizantes:en un momento dado, se puede enviar hasta una ventana de información sin haberrecibido los acuses de recibo del destino. Cuando la latencia es muy grande comoen una red satelital, y/o cuando el ancho de banda es muy grande como una rednacional a velocidades de gigabits por segundo, el tamaño de la ventana puederesultar demasiado pequeño “para llenar el ducto” de comunicación entre la fuentey el destino con información en tránsito. Si esto ocurre, la fuente debe detener suemisión, degradando la eficiencia de la red.

El RFC-1323 propone varias extensiones a TCP para tratar este problema. La prin-cipal de ellas es el uso de ventanas mayores al tamaño estándar de 64kBytes. Juntocon esta extensión, se proponen mecanismos para medir con mayor precisión elRTT de la conexión y protecciones contra el eventual reciclado de números de se-cuencia.

3.17Muchos estudios recientes han mostrado que el tráfico generado por las aplicacionesde red se desvían considerablemente de un proceso de Poisson. Un modelo másapropiado para el tráfico de red parece requerir distribuciones con “cola larga” comola distribución Pareto. Algo que aparentemente puede ser modelado por Poisson sonlos procesos humanos.

En VoIP, el número de inicios de llamada en un intervalo de tiempo podría serPoisson y la duración de una llamada podría ser exponencial, pero la generación depaquetes dentro de una llamada es muy probable que no pueda ser un proceso dePoisson.

Diseño lógico

4.2

Firewall: en la capa de distribución;

VLANs: en de distribución y de acceso, depende de la complejidad de la red;

Mecanismo de despacho de colas: en el núcleo para implementar PHBs. Si la redes muy grande, tal vez se requieran también en las otras dos capas.

Diseño y Arquitectura de Redes Telemáticas 197

Page 208: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 8. RESPUESTAS A PROBLEMAS SELECCIONADOS

4.5NODO K = 3 Vecinos Ocurrencias

1 2, 5, 6 12 3, 4, 5 63 2, 4, 5 34 2, 3, 5 65 2, 4, 6 76 2, 4, 5 57 5, 6, 8 48 4, 6, 7 49 7, 8, 10 2

10 7, 8, 9 2

Frecuencia Repeticiones1 12 23 14 25 16 27 1

v̄ =⌊ F

Σj=1Sj × j

N

⌋+ 1 =

1 + 4 + 3 + 8 + 5 + 12 + 7

10= 4

Los mejores candidatos son aquéllos > v̄, es decir, 2, 4, 5, 6

4.8

1

2 3

4 5

(1)

(2)

(5)

(4)

(3)

4.10Existen varias soluciones, entre otras:

Diseño y Arquitectura de Redes Telemáticas 198

Page 209: Diseño y Arquitectura de Redes Telemáticas

4 1 3 2 5

4 5 2 3 1

2 5 4 1 3

4.15

Administración de Redes

5.1

Gestión de fallas. Se encarga de localizar, aislar y corregir problemas en la red.

Gestión de configuración. Es el proceso de obtener datos e información de la redy utilizarlos para gestionar la configuración de los diferentes dispositivos.

Gestión de seguridad. La gestión de seguridad no se limita a los mecanismos deseguridad (protocolos, mecanismos de encripción, etc.) sino a toda la políticade seguridad que debe implantarse: administración de contraseñas; responsa-bilidades de los usuarios; seguridad de acceso físico; etcétera.

Gestión de rendimiento. Garantizar el acceso contínuo y eficiente a la red me-diante el monitoreo de los dispositivos de red y sus enlaces asociados paradeterminar su utilización, niveles de error, etcétera.

Gestión contable. Almacena y procesa datos referentes al consumo de los recursosde la red. Esta información puede ser utilizada para fines de cobro y tambiéncomo apoyo para planear la capacidad y/o detectar fallas.

5.5

• Retiene las mejores propuestas de la versión 2 en cuanto a rendimiento (Get-Bulk, Inform, contadores >64 bits) y la comunicación administrador - admi-nistrador.

Diseño y Arquitectura de Redes Telemáticas 199

Page 210: Diseño y Arquitectura de Redes Telemáticas

CAPíTULO 8. RESPUESTAS A PROBLEMAS SELECCIONADOS

• Unifica los mecanismos de seguridad: encripción y autenticación.

• Incorpora mecanismos de administración de agentes.

• Define relaciones entre objetos.

• Proporciona más flexibilidad para definir el protocolo de transporte.

5.6

02 03 FE 3A 04 // int x = 0xFE3A04;09 02 <1.23> 09 02 <4.0> // float y[2] = {1.23, 4.0};16 16 // struct {28 11 ’L’’u’’i’’s’’ ’’F’’e’’l’’i’’p’’e’ //char nombre =‘‘Luis Felipe’’;02 01 19 // int edad = 25;01 01 00 //boolean casado = 0; } status;28 01 ’K’ //char seccion = ’K’;

Diseño y Arquitectura de Redes Telemáticas 200