• Author / Uploaded
• Lola

Citation preview

Análisis de redes, arquitectura y diseño TERCERA EDICIÓN

La serie de Morgan Kaufmann en redes Redactor de la serie, David Clark, M.I.T.

Análisis de redes, arquitectura y diseño, 3e James D. McCabe Inalámbrico de comunicaciones y redes: una introducción Vijay K. Garg Ethernet redes para la pequeña oficina y profesional Ministerio del interior Jan L. Harrington Avanzada aplicación de protocolos IPv6 Li Qing, Tatuya Jinmei y Keiichi Shima Redes de computadoras: Un enfoque de sistemas, 4e Larry L. Peterson y Bruce S. Davie Encaminamiento de red: arquitecturas, protocolos y algoritmos Deepankar Medhi y Karthikeyan Ramaswami Implementación de IP y MPLS QoS para redes multiservicio: Teoría y práctica John Evans y Clarence Filsfils Ingeniería de tráfico y QoS optimización de integrado Voz y redes de datos Gerald R. Ash Implementación de protocolos de base de IPv6 Li Qing, Tatuya Jinmei y Keiichi Shima Inteligente de teléfono y la informática móvil de próxima generación PEI Zheng y Lionel Ni GMPLS: arquitectura y aplicaciones Adrian Farrel y Igor Bryskin Seguridad de red: un enfoque práctico Jan L. Harrington Redes de contenido: Arquitectura, protocolos y prácticas Markus Hofmann y Leland R. Beaumont Red de algoritmos: Un enfoque interdisciplinario en Diseño rápido en red dispositivos George Varghese Recuperación de la red: Protección y restauración de ópticas, SONET SDH, IP y MPLS Jean Philippe Vasseur, Mario Pickavet y Piet Demeester

Enrutamiento, flujo y diseño de capacidad de comunicación y Redes de computadoras Michał Pióro y Deepankar Medhi Redes de sensores inalámbricas: un enfoque de procesamiento de información Feng Zhao y Leonidas Guibas Redes privadas virtuales: la conexión derecha Dennis Fowler Aplicaciones en red: Una guía a la informática nuevo Infraestructura David G. Messerschmitt Diseño de redes de área amplia: conceptos y herramientas para la optimización de Robert S. Cahn Redes de comunicación: un enfoque analítico Anurag Kumar, D. Manjunath y alegría Kuri Internet y sus protocolos: un enfoque comparativo Adrian Farrel Televisión moderna tecnología: Video, voz y datos comunicaciones, 2e Walter Ciciora, granjero de James, grande, David y Michael Adams Programación de aplicaciones de Bluetooth con el API de Java C. Bala Kumar, Paul J. Kline y Timothy J. Thompson Gestión de red basado en políticas: Soluciones para la siguiente Generación John Strassner Dirección de la red de MPLS: MIB, herramientas y técnicas Thomas D. Nadeau Desarrollar servicios basados en IP: Soluciones para proveedores de servicios y proveedores Monique Morrow y Kateel Vijayananda Ley de telecomunicaciones en la era de Internet Sharon K. Black Redes ópticas: Una perspectiva práctica, 2e Rajiv Ramaswami y Kumar N. Sivarajan QoS en Internet: Arquitecturas y mecanismos Zheng Wang Sockets de TCP/IP en Java: Guía práctica para programadores Michael J. Donahoo y Kenneth L. Calvert Sockets de TCP/IP en C: Guía práctica para programadores Kenneth L. Calvert y Michael J. Donahoo Comunicación multicast: Aplicaciones, programación y protocolos Ralph Wittmann y Martina Zitterbart MPLS: tecnología y aplicaciones Bruce Davie y Yakov Rekhter Redes de comunicación de alto rendimiento, 2e Jean Walrand y Pravin Varaiya Interconexión de redes Multimedia Jon Crowcroft, Mark Handley y Ian Wakeman Comprensión de aplicaciones en red: un primer curso de David G. Messerschmitt Manejo integrado de sistemas en red: conceptos,

Arquitecturas y su aplicación operativa Heinz Gerd Hegering, Sebastian Abeck y Bernhard Neumair

Para más información sobre estos libros y una lista de próximos títulos, por favor visite nuestro sitio Web en http:// www.mkp.com.

Análisis de red, Arquitectura y diseño TERCERA EDICIÓN

James D. McCabe

Amsterdam • Boston • Heidelberg • Londres Nueva York • Oxford • París • San Diego San

Francisco • Singapur • Sydney • Tokio Morgan Kaufmann Publishers es una impresión de Elsevier

Adquisiciones Editor Rick Adams Editorial servicios Gerente de George Morrison Editorial Assistant Kimberlee Honjo Servicios de composición Integra Software Corrector de estilo Carol Leyba

Correctora de Phyllis Coyne et al servicio de corrección Indizador Michael Ferreira Impresora de interior el grupo arce-Vail Cubierta de la impresora Color Phoenix Corporation Cubierta diseño Dick Hannus Cubierta a imagen Hari Hoffman "Enseñanza espacio a curva" (puente del reloj de sol)

Morgan Kaufmann Publishers es una impresión de Elsevier. 30 Corporate Drive, Suite 400, Burlington, MA 01803, USA que este libro está impreso en papel libre de ácido. © 2007 Elsevier Inc. Todos los derechos reservados. Denominaciones utilizadas por las empresas para distinguir sus productos con frecuencia se afirma como marcas comerciales o marcas registradas. En todas las instancias en que editores de Morgan Kaufmann es consciente de una reclamación, los nombres de los productos aparecen en capital inicial o todas mayúsculas. Los lectores, sin embargo, deben comunicarse con las empresas adecuadas para obtener información más completa acerca de marcas y registro. Ninguna parte de esta publicación puede reproducirse, almacenada en un sistema de recuperación o transmitida en cualquier forma o por cualquier medio, electrónico, mecánico, Fotocopiado, escaneado u otro, sin consentimiento previo por escrito del editor. Permisos pueden solicitarse directamente con la ciencia de Elsevier y tecnología Departamento de derechos en Oxford, Reino Unido: teléfono: (+ 44) 843830 1865, fax: (+ 44) 1865 853333, correo electrónico: [email protected]. También puede completar su solicitud en línea a través de la Página Web de Elsevier (http://elsevier.com), seleccionando "Ayuda y contacto" y "derechos de autor y permiso" y luego "obtener permisos". Biblioteca de datos de catalogación en publicación de Congreso (Solicitado) ISBN: 978-0-12-370480-1 Para obtener información sobre todas las publicaciones de Morgan Kaufmann, visite nuestro sitio Web en www.mkp.com o www.books.elsevier.com Impreso en los Estados Unidos de América 07 08 09 10 11 10 9 8 7 6 5 4 3 2 1

Trabajando juntos para hacer crecer las bibliotecas en los países en desarrollo www.Elsevier.com | www.bookaid.org | www.Sabre.org

Dedicación

Para Juan y Ruth, Ron y Pam, Seana y Riley. Esto es también para Shelby, cuya habilidad artística se esfuerzan por reproducir en mis escritos.

Esta página dejada intencionadamente en blanco

Prólogo Tercera edición de Jim McCabe de Análisis de redes, arquitectura y diseño define un enfoque disciplinado para la arquitectura y el diseño de la red. Enfoque de Jim aborda los elementos críticos necesarios para diseñar y desplegar redes en un entorno cada vez más complejos con éxito. Hay una presión constante para implementar nuevas características y servicios aumentando la calidad de la seguridad de red y servicios existente. Además, las fuerzas del mercado están presionando a los operadores de red para administrar cerca inversión en nueva infraestructura y reducir costos de mantenimiento y operaciones. En los tres años desde que Jim publicó la segunda edición el paisaje ha cambiado radicalmente. Ya no es posible equipan la red y esperar a "crecer" en él. Servicios, voz sobre IP, convergentes y emergentes IPv6 implementaciones están obligando a arquitectos de la red para volver a los fundamentos de las mejores prácticas de ingeniería. Enfoque de Jim en análisis de requerimientos, diseño trazabilidad y métricas de diseño está situado en destino. Jim ha desarrollado una metodología repetible, madura, que cuando se siguió correctamente, produce redes escalables y bien diseñadas. No se trata de un libro sobre la teoría de la arquitectura de red y el diseño, es una guía práctica basada en la riqueza de Jim de la experiencia. Los conceptos han sido probados en la implementación exitosa de numerosas redes. El momento de esta edición no podía ser mejor. Estamos en el inicio de una transición importante, implementar la próxima generación de redes. Jim ofrece la orientación para arquitecto e implementarlas con éxito. Departamento de comercio de John McManus, Estados Unidos

VII

Esta página dejada intencionadamente en blanco

Contenido

Prefacio vii Prefacio xvii Agradecimientos xix

1 Introducción 1.1 Objectives 3 1,2 Preparación de la 3 1.3 Background 3 1.4 Resumen de análisis, arquitectura y diseño de procesos 6 1.4.1 Componentes de proceso 9 1.4.2 Importancia táctica y estratégica 12 1.4.3 Jerarquía y diversidad 14 1.4.4 Importancia del análisis de red 18 1.4.5 Modelo de análisis de redes, arquitectura y diseño 24 1.5 Una metodología de sistemas 27 1.6 Descripción del sistema 27 1.7 Descripción del servicio 31 1.8 Características de servicio 33 1.8.1 35 niveles de servicio 1.8.2 Componentes del sistema y servicios de red 36 1.8.3 Las solicitudes de servicio y requisitos 39 1.8.4 Ofertas de servicio 43 1.8.5 Métricas de servicio 45 1.9 Características de funcionamiento 47 1.9.1 Capacidad 47 1.9.2 Demora 48 1.9.3 RMA 48 1.9.4 Rendimiento sobres 50 1.10 Soporte de red 51 1,11 Conclusión 53 1,12 ejercicios 54

IX

Contenido

2 Análisis de requerimientos: conceptos 2.1 Objectives 57 2.1.1 Preparation 57 2.2 Background 58 2.2.1 Requisitos y funciones 58

2.2.2 La necesidad de análisis de requerimientos 61 2.3 Requisitos de usuario 62 2.4 Requisitos de la aplicación 66 2.4.1 Tipos de aplicación 67 2.4.2 Grupos de aplicaciones 73 2.4.3 Lugares de aplicación 75 2.5 Requisitos del dispositivo 76 2.5.1 Tipos de dispositivos 77 2.5.2 Características de rendimiento 80 2.5.3 Ubicaciones del dispositivo 81 2.6 Requisitos de la red 83 2.6.1 Las redes y migración 84 2.6.2 Administración de redes y seguridad 85 2.7 Otros requisitos 88 2.7.1 Prescripciones adicionales 88 2.7.2 Requisitos financieros 89 2.7.3 Requerimientos de las empresas 90 2.8 Los requisitos de especificación y mapa 90 2.9 Conclusions 94 2.10 Exercises 95

3 Análisis de requerimientos: proceso 3.1 Objectives 99 3.1.1 Preparation 99 3.2 Encuentro y listado de requisitos 100 3.2.1 Determinar las condiciones iniciales 100 3.2.2 Ajuste de las expectativas del cliente 104 3.2.3 Trabajar con usuarios 105 3.2.4 Medición de desempeño 106 3.2.5 Seguimiento y gestión de requisitos 107 3.2.6 Mapeo de información 109 Contenido

Métricas de servicio en desarrollo 3,3 109 3.3.1 herramientas de medición 111 3.3.2 donde aplicar métricas de servicio 112 3.4 caracterización del comportamiento 113 3.4.1 modelado y simulación 113 3.4.2 comportamiento del usuario 115 3.4.3 aplicación comportamiento 116 3.5 desarrollar requisitos de RMA 117 3.5.1 fiabilidad 117 3.5.2 mantenimiento 118

3.5.3 disponibilidad 118 3.5.4 los umbrales y los límites 124 3.6 desarrollar requisitos de retardo 125 3.6.1 retrasos end-to-End e ida y vuelta 128 3.6.2 variación de retardo 130 Requisitos de capacidad en desarrollo 3,7 130 3.7.1 estimación de tarifas de datos 130 Requisitos de rendimiento suplementario de desarrollo 3,8 133 3.8.1 idoneidad operativa 134 3.8.2 soporte 137 3.8.3 confianza 143 3,9 umbrales específicos de medio ambiente y los límites 145 3.9.1 comparar requisitos de la aplicación 146 3.10 requisitos de previsible y garantizada Rendimiento 147 3.10.1 requisitos para Performance predecible 147 3.10.2 requisitos para rendimiento garantizado 148 3,11 Requisitos mapeo 149 3.12 desarrollo de la especificación de requisitos 151 3,13 conclusiones 155 3,14 ejercicios 155

4 Análisis de flujo 4,1 objetivos 161 4.1.1 preparación 161 4.2 fondo 162 4.3 flujos 162 4.3.1 flujos individuales y compuestos 164 4.3.2 flujos críticos 166 4.4 identificación y desarrollo de flujos de 167 4.4.1 centrándose en una aplicación Particular 169 4.4.2 desarrollo de un perfil 172 4.4.3 elegir las aplicaciones Top N 173 4,5 datos fuentes y fregaderos 175 4.6 modelos de flujo 180 4.6.1 peer-to-Peer 181 4.6.2 cliente – servidor 183 4.6.3 jerárquica cliente – servidor 185 4.6.4 computación distribuida 188 4.7 flujo de priorización 191 4.8 la especificación de flujo 193 4.8.1 algoritmo Flowspec 195 4.8.2 servicio planificación y capacidad 197 4.9 ejemplo de aplicación de análisis de flujo 197 4,10 conclusiones 205 4,11 ejercicios 206

5 Arquitectura de red 5,1 objetivos 211

5.1.1 preparación 211 5.2 fondo 211 5.2.1 arquitectura y diseño 213 Arquitecturas de componente 5,3 215 5.3.1 abordar/enrutamiento de arquitectura de componentes 220 5.3.2 gestión arquitectura de componentes de red 222 5.3.3 arquitectura de componentes de rendimiento 223 5.3.4 arquitectura de componentes de seguridad 225 5.3.5 optimización de arquitecturas de componentes 226 5.4 arquitectura de referencia 227 5.4.1 relaciones externas 229 5.4.2 optimizar la arquitectura de referencia 230 Modelos arquitectónicos 5,5 232 5.5.1 modelos topológicos 232 5.5.2 modelos basados en el flujo 234

Contenido

5.5.3 Modelos funcionales 237 5.5.4 Utilizando los modelos arquitectónicos 238 5.6 Sistemas y arquitecturas de red 244 5.7 Conclusiones 245 5.8 Ejercicios 246

6 Direccionamiento y enrutamiento de arquitectura 6.1 Objetivos 249 6.1.1 Preparación 249 6.2 Fondo 250 6.2.1 Abordar los fundamentos 251 6.2.2 Fundamentos 253 de ruta 6.3 Abordar mecanismos 257 6.3.1 Classful abordar 257 6.3.2 Subredes 259 6.3.3 Subnetting de longitud variable 262 6.3.4 Supernetting 264 6.3.5 Direccionamiento privado y NAT 268 6.4 Enrutamiento de mecanismos 269 6.4.1 Establecer flujos de enrutamiento 269 6.4.2 Identificar y clasificar enrutamiento límites 270 6.4.3 Manipulación de enrutamiento fluye 273 6.5 Abordar estrategias 278 6.6 Enrutamiento de estrategias 280 6.6.1 Evaluación de protocolos de enrutamiento 282

6.6.2 Elección y aplicación de protocolos de enrutamiento 287 6.7 Consideraciones sobre la arquitectura 291 6.7.1 Relaciones internas 291 6.7.2 Relaciones externas 292 6.8 Conclusions 293 6.9 Exercises 293

7 Arquitectura de gestión de red 7.1 Objectives 299 7.1.1 Preparation 299 7.2 Background 300 7.3 Definición de gestión de red 300 7.3.1 Dispositivos de red y características 302 7.4 Mecanismos de gestión de red 303 7.4.1 304 de mecanismos de vigilancia 7.4.2 Mecanismos de instrumentación 308 7.4.3 Mecanismos de configuración 310 7.5 Consideraciones sobre la arquitectura 311 7.5.1 Gestión en banda y fuera-de-banda 312 7.5.2 Administración centralizada, distribuida y jerárquica 315 7.5.3 Escala gestión tráfico 318 7.5.4 Controles y equilibrios 319 7.5.5 Gestión de red gestión datos 319 7.5.6 Selección de MIB 322 7.5.7 Integración en OSS 323 7.5.8 Relaciones internas 323 7.5.9 Relaciones externas 326 7.6 Conclusions 328 7.7 Exercises 328

8 Arquitectura de rendimiento 8.1 Objectives 333 8.1.1 Preparation 333 8.2 Background 334 8.3 Desarrollo de objetivos de rendimiento 335 8.4 Mecanismos de funcionamiento 338 8.4.1 Calidad de servicio 338 8.4.2 Priorización, gestión del tráfico, colas y programación, 342 8.4.3 Acuerdos de nivel de servicio de 348 8.4.4 Políticas 351 8.5 Consideraciones sobre la arquitectura 351 8.5.1 Evaluación de desempeño mecanismos 352 8.5.2 Relaciones internas 354 8.5.3 Relaciones externas 354

8.6 Conclusiones 355 8.7 Ejercicios de 356 Contenido

9 Arquitectura de la privacidad y seguridad 9.1 Objetivos 359 9.1.1 Preparación 359 9.2 Fondo 360 9.3 Desarrollo de una seguridad y privacidad Plan 361 9.4 Seguridad y privacidad administración 362 9.4.1 Análisis de las amenazas 362 9.4.2 Políticas y procedimientos 365 9.5 Seguridad y privacidad mecanismos 367 9.5.1 Seguridad física y conciencia 368 9.5.2 Protocolo y seguridad de aplicaciones 369 9.5.3 Cifrado/descifrado 371 9.5.4 Seguridad perimetral de red 373 9.5.5 Seguridad de acceso remoto 374 9.6 Consideraciones sobre la arquitectura 377 9.6.1 Evaluación de mecanismos de seguridad 377 9.6.2 Relaciones internas 380 9.6.3 Relaciones externas 380 9.7 Conclusiones 381 9,8 ejercicios 382

10 Diseño de redes 10.1 Objetivos 386 10.1.1 Preparación 386 10.2 Conceptos de diseño 386 10.2.1 Analogía con un diseño de edificio 389 10.2.2 Diseño productos 390 10.2.3 Entrada al diseño 393 10.3 Proceso de diseño 394 10.4 Proveedor, el equipo y evaluaciones de servicios 395 10.4.1 Siembra el proceso de evaluación 397 10.4.2 Debates de candidatos 398 10.4.3 399 de recopilación de datos 10.4.4 Refinamiento de criterios y calificaciones desarrollo 401 10.4.5 Clasificación y priorización 403 10.4.6 Modificar el conjunto de candidatos 405 10.4.7 Determinar el orden de las evaluaciones 407 10.5 Diseño de la red 408

10.5.1 Diagramas de lógicas 408 10.5.2 Planos de red 409 10.5.3 Componente planes de 419 10.6 Diseño trazabilidad 422 10.7 Métricas de diseño 428 10,8 Conclusiones 429 10,9 Ejercicios de 431

GLOSARIO DE TÉRMINOS 433 GLOSARIO DE SIGLAS 451 ÍNDICE 462

Prefacio Análisis de redes, arquitectura y diseño, tercera edición trata de tomar decisiones de ingeniería de red inteligente, informado. Esto incluye los procesos para desarrollar y validar los requerimientos de su proyecto y aplicar decisiones de arquitectura y diseño. Estos procesos han sido adoptados por las corporaciones, universidades y agencias de gobierno alrededor del mundo. Aunque este libro se centra en las redes, los procesos de toma de decisiones puede aplicarse a cualquier proyecto de Ingeniería Informática, de desarrollo nacional de la red para una LAN pequeña empresa, de una actualización de red general para centrarse en las capacidades particulares como VPNs, QoS, o MPLS. Por ejemplo, los procesos en este libro se han aplicado recientemente a los proyectos para el desarrollo de un perímetro de seguridad externo (como parte de una estrategia de defensa en profundidad) y una arquitectura de direccionamiento IPv6. Durante los diez años que abarcan las publicaciones de las ediciones primeras y segunda de Análisis de redes, arquitectura y diseño , varios conceptos en este libro han entrado en la corriente principal de ingeniería de red. Análisis de flujo de tráfico y el acoplamiento de los requisitos para los flujos de tráfico, es cada vez más importante en la provisión de seguridad y el rendimiento en toda la red. Desarrollar y validar requisitos para preparar formalmente para el diseño de la red son esenciales para asegurar la precisión y consistencia en el diseño. Análisis de redes, arquitectura y diseño, tercera edición proporciona una sección de diseño actualizado que incluye cómo evaluar y seleccionar proveedores, productos y proveedores de servicios, así como la diagramación del diseño. También se actualizaron las secciones de análisis para requisitos par a la arquitectura y diseño, incluyendo la trazabilidad y validación de requisitos.

Enfoque

Análisis de redes, arquitectura y diseño, tercera edición le ayudará a entender y definir la arquitectura de red y el diseño. Examina todo el sistema, de los usuarios y sus aplicaciones, dispositivos y redes que los apoyan. XVII Prefacio

Este libro está diseñado para aplicarse a pregrado y postgrado en programas de ingeniería de redes, arquitectura y diseño, así como para estudio profesional para ingenieros y gestión (incluyendo CTOs y CIOs). Está estructurado para seguir la progresión lógica de análisis, desarrollo y validación de requisitos, que constituyen la base para la toma de decisiones con respecto a la arquitectura de red, que a su vez forma la base para la toma de decisiones de diseño de red.Cuando enseño el análisis de redes, arquitectura y diseño en las universidades, corporaciones o conferencias, me parece que los estudiantes fácilmente adaptan el material en este libro como parte de su proceso de ingeniería. En este libro, proporcionará procedimientos paso a paso para hacer el diseño, la arquitectura y el análisis de redes. Han refinado este proceso a través de años de arquitectura y diseño de redes a gran escala para agencias gubernamentales, universidades y corporaciones y han incorporado las ideas y experiencias de expertos diseñadores en todo el libro. Como un estándar abierto para una tecnología o protocolo, los procedimientos en este libro son el resultado de varias contribuciones y le ofrecen la experiencia acumulada de muchos diseñadores y arquitectos de red. Abordar algunos de los problemas difíciles en el análisis de redes, arquitectura y diseño y abordar retos real de arquitectura y diseño, incluyendo cómo: • Se reúnen, derivar, definir y validar los requerimientos reales de la red • Determine cómo y dónde se implementan direccionamiento y enrutamiento, seguridad, gestión

de red y rendimiento en la red, y cómo interactúan entre sí • Evaluar y seleccionarlos proveedores, productos y proveedores de servicios para su proyecto • Desarrollo de la trazabilidad entre requerimientos, decisiones de arquitectura y las decisiones de

diseño • Determinar dónde aplicar protocolos de enrutamiento (RIP/RIPv2, OSPF, BGP-4, MPLS), así como

mecanismos de direccionamiento de IP de clase y sin clase • Determinar dónde aplicar mecanismos de funcionamiento, incluyendo la calidad de servicio,

acuerdos de nivel de servicio y políticas en la red Para hacer frente a retos como estos, proporcionan guías, ejemplos y principios generales para ayudarle en la toma de decisiones difíciles. Usted puede encontrar algunos o todos ellos para ser útil, y os animo a modificarlos para sus necesidades, arquitectura y diseño. Prefacio XIX

Para aquellos que utilizan este libro en una clase o para estudio, hay una serie de ejercicios al final de cada capítulo. Además, la Página Web de este libro en el sitio del editor Web (www.mkp.com) contiene material adicional útil en su progreso a través del libro, así como un manual de contraseña soluciones a los ejercicios disponibles para instructores.

Hoja de ruta Los cuatro primeros capítulos se basan en el enfoque de sistemas, análisis de requerimientos y análisis de flujo de la primera edición. Se han actualizado para incluir cambios y mejoras en el análisis de redes desde el lanzamiento de la segunda edición. Capítulo 1 presenta análisis de red, incluyendo el enfoque de sistemas y proporciona las definiciones y conceptos que se utilizarán en todo el libro. Capítulos 2 y 3 enfoque en los conceptos y el proceso de determinar los requisitos para su red y el capítulo 4 analiza cómo puede utilizarse análisis de flujo de tráfico para requerimientos de performance de la pareja a diferentes flujos de tráfico. Capítulos 5 al 9 cubre el proceso de arquitectura de red. Capítulo 5 proporciona una introducción a la arquitectura de red, desarrollo de relaciones internas y externas dentro de y entre las funciones principales (direccionamiento y enrutamiento, seguridad, administración de redes y performance) en la red. En los capítulos 6 a 9 se detallan cada una de estas funciones principales, desarrollo de arquitecturas de referencia y componentes que describen sus relaciones internas y externas. Capítulo 10 analiza el proceso de diseño. Toma los resultados de los capítulos anteriores y aplica hacia diseño de decisiones, incluyendo cómo evaluar y seleccionarlos proveedores, productos y proveedores de servicios y Diagramación del diseño. Para capítulos apropiados, he proporcionado una lista de lectura recomendada será útil en la comprensión de los conceptos de este capítulo. Puesto que este libro presenta a un buen número de nuevos conceptos, también proporcionan un extenso Glosario de acrónimos y términos que se utilizan en todo el libro.

Agradecimientos En primer lugar, muchas gracias a Pat Dunnington (NASA) y John McManus (Departamento de comercio) por darme la oportunidad de refinar el último diseño Prefacio

conceptos durante mi tiempo en la NASA. También me gustaría agradecer a Havi Hoffman por uso de su foto "Enseñanza espacio a curva" como la portada de este libro. Además, gracias a Tony Arviola y Bessie Whitaker de la NASA por su ayuda en la adopción de los conceptos de este libro y aplicarlas a varios proyectos de ingeniería a través de la NASA. El material presentado en este libro se basa en una recopilación de mis propias experiencias profesionales y los de otros miembros de la comunidad de redes. Como siempre, yo soy

responsable de cualquier error en este libro. Análisis, arquitectura y procesos de diseño están en constante evolución, y cualquier comentario de usted sobre cómo mejorar estos procesos es más agradable. Preguntas, comentarios y sugerencias pueden enviarse a me en [email protected] o a través de Morgan Kaufmann editorial. La gente de Morgan Kaufmann editorial ha sido una maravillosa influencia en el desarrollo de esta edición. Muchas Gracias Dr. David Clark (redactor) de la serie, Rick Adams (Editor de adquisiciones Senior), Rachel Roumeliotis (Editor asociado) y Kathryn Liston (Project Manager). Los capítulos de requisitos y análisis de flujo se basan en trabajo temprano sobre el análisis de flujo de datos hecho mientras estaba en el centro de simulación aerodinámica numérica (NAS) en el centro de investigación NASA Ames en Mountain View, CA. Le debo mucho gracias a Bruce Blaylock, quien tuvo la visión de futuro a este trabajo, así como la tenacidad para ayudarme en el proceso.

Esta página dejada intencionadamente en blanco

CAPÍTULO CONTENIDO 1.1 Objetivos 1.2 Preparación 1.3 Fondo 1.4 Resumen de análisis, arquitectura y diseño de procesos 1.4.1 Componentes de proceso de 1.4.2 Importancia táctica y estratégica 1.4.3 Jerarquía y diversidad 1.4.4 Importancia del análisis de red 1.4.5 Modelo de análisis de redes, arquitectura y diseño 1.5 Una metodología de sistemas 1.6 Descripción del sistema 1.7 Descripción del servicio 1.8 Características del servicio 1.8.1 Niveles de servicio 1.8.2 Componentes del sistema y servicios de red 1.8.3 Requisitos y solicitudes de servicio

1.8.4 Ofertas de servicio

1.8.5 Métricas de servicio 1.9 Características de rendimiento 1.9.1 Capacidad 1.9.2 Retardo de 1.9.3 RMA 1.9.4 Sobres de rendimiento 1.10 Soporte de red 1.11 Conclusión 1.12 Ejercicios

2

1 Introducción Comenzar este libro con una descripción de los análisis, arquitectura y procesos de diseño. Muchos de los conceptos y términos utilizados a lo largo de este libro son introducidos y definidos en este capítulo. Algunos de estos conceptos pueden ser nuevos para usted, mientras que otras se presentan bajo una luz diferente. Glosarios de términos y acrónimos se presentan al final de este libro para una fácil referencia.

1.1 Objetivos En este capítulo voy a introducir los conceptos fundamentales de este libro: que la red es parte de un sistema que proporciona servicios a sus usuarios finales; que existen procesos para el desarrollo de un análisis, una arquitectura y un diseño de una red; y que hay maneras de caracterizar una red.

1.2 Preparación Con el fin de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con los conceptos básicos de redes. Esto incluye las funciones y características de la TCP/IP protocol suite, tecnologías como las variantes de Ethernet, red óptica síncrona (SONET) y división de onda (WDM), la multiplexación y los fundamentos de la red de enrutamiento, seguridad, rendimiento, y gestión.

1.3 Fondo Diseño, arquitectura y análisis de red han tradicionalmente se ha considerado arte, combinando reglas específicas de un individuo en evaluación y elección de tecnologías de red, conocimiento sobre cómo pueden ser tecnologías, servicios y protocolos significativo combinado; experiencia en lo que funciona y qué no; junto con las selecciones (a menudo arbitrarias) de arquitecturas de red. Sin embargo, como con otros tipos de arte, éxito de un diseño de red determinada a menudo depende sobre todo de quién está haciendo 3 el trabajo, con resultados que son raramente reproducibles. Esto puede haber sido aceptable en los primeros días de trabajo en red, cuando las redes fueron más un hobby que un recurso crítico y no apoyó directamente la generación de ingresos. Hoy, sin embargo, las redes están integradas dentro de nuestro trabajo, casa y fuera de ambientes. Se consideran "críticos"[1] para el éxito corporativo y proporciona cerca de en tiempo real acceso a la información en todo el mundo. Como tal, el diseño de una red debe ser lógico, reproducible y defendible. Esta premisa es el fundamento de este libro. Tradicionalmente, diseño, arquitectura y análisis de redes se han basado en el desarrollo y aplicación de un conjunto de reglas para la red. En el desarrollo de un conjunto de reglas, una persona puede dibujar desde mi experiencia personal, así como del general reglas como la regla 80/20 (donde el 80% del tráfico de una red es local y 20% es remoto) o el Adagio "puente cuando puede, la ruta cuando usted debe" (puente siendo más simple más fácil y más barato en el momento). Como vemos más adelante en este libro, aunque estas reglas son antiguos desde la perspectiva de la historia de redes, siguen aplicando hoy en día, aunque en forma modificada. Estas normas eran útiles cuando no había muchas opciones en tecnologías de redes y servicios, y se entendieron claramente las diferencias entre opciones. Pero los tiempos han cambiado y nuestra noción de diseño de redes debe adaptarse a la variedad de opciones ahora disponibles para nosotros, la variedad de servicios que las redes puede ofrecer a los usuarios finales y los sutiles matices provocaron por la combinación de tecnologías de red, técnicas, y servicios.

Ejemplo 1.1. Considerar las sutilezas en el comportamiento de la red introducido mediante el uso de redes privadas virtuales, intranets, o redes privadas virtuales de VPNs. son muy útiles; sin embargo, se debe tener cuidado para entender su potencial impacto en seguridad de red, enrutamiento y gestión. Desde el túnel de VPN (encapsular) y puede cifrar el tráfico que fluye a través de una red, a menudo requieren más esfuerzo para asegurar, controlar y administrar. Se considerará como VPNs impactan seguridad, enrutamiento y gestión durante el proceso de la arquitectura.

Análisis de red, diseño y arquitectura, se han centrado tradicionalmente en planificación de la capacidad , que es exceso de ingeniería una red para proporcionar una cantidad de capacidad (también conocido como banda) estimado para acomodar más corto y a largo plazo tráfico fluctuaciones durante el ciclo de vida del diseño. El resultado es un ancho de banda

Fondo

"buffer" que puede manejar estas fluctuaciones. Tráfico de la red crece con el tiempo, este buffer de ancho de banda se reduce, y los usuarios experimentar problemas relacionados con la congestión del tráfico. Se trata de un uso ineficiente de recursos de red, derrochando dinero por adelantado en recursos no utilizados sin lograr aportar la flexibilidad necesaria para adaptarse a los requerimientos cambiantes de tráfico de los usuarios. Ancho de banda es solo un componente de los recursos de red que debemos tener en cuenta. También tenemos que considerar cómo retrasar a través de la red, así como fiabilidad, mantenibilidad, de red y disponibilidad (RMA), puede ser optimizado. En evolución redes actuales, retardo y confiabilidad pueden ser más importantes que la capacidad. En este libro exploramos cómo han cambiado los análisis, arquitectura y procesos de diseño y cómo continúan cambiando. Discutimos cómo estos procesos trabajan juntos en una red nueva o existente de ingeniería. Nos acercamos a las redes desde una perspectiva diferente, como un sistema de prestación de servicios a sus usuarios, y discutimos cómo las redes pueden ser diseñadas para proporcionar diferentes tipos de servicios a los usuarios. En la adopción de este enfoque destacamos análisis de red, que nos ayuda a entender lo que se requiere de una red en el apoyo a sus clientes y sus aplicaciones y dispositivos. Como veremos, estos procesos requieren una inversión en tiempo y esfuerzo, pero el retorno de la inversión es significativo. Estos son poderosas herramientas que pueden ayudar a construir mejores redes, mejorando la capacidad de su organización para realizar su trabajo. Este libro comienza aplicando una metodología de sistemas en redes. Esta metodología es relativamente nueva, y usted aprenderá una serie de definiciones útiles en relación con el análisis de redes, arquitectura y diseño. Lógicamente, el resto de este libro se divide en tres secciones. La primera sección cubre el proceso de análisis: específicamente, cómo desarrollar requisitos, entender los flujos de tráfico y realizar un análisis de riesgo. El proceso de análisis te prepara para hacer frente a la arquitectura de red, en la segunda sección. Aquí se describe cómo tomar decisiones tecnología y topología de la red, cómo entender las relaciones entre las distintas funciones dentro de su red y cómo utilizar esta información para desarrollar una arquitectura. En la sección final la arquitectura de red se utiliza como entrada para el proceso de diseño, donde selecciones de información, equipos y proveedores de ubicación se utilizan para el diseño de detalle. Flujos de información entre el análisis, arquitectura y diseño de procesos se presentan en la figura 1.1. Diseño, arquitectura y análisis de red le ayudará a identificar y aplicar servicios de red y prestaciones necesarios para satisfacer a sus usuarios. A través de estos procesos será capaz de entender los problemas que está tratando de dirección con la nueva red; determinar los objetivos de servicio y rendimiento

Figura 1.1 flujo de información entre el análisis de redes, arquitectura y diseño

necesarios para abordar estos problemas; Arquitecto y diseñar la red para ofrecer los servicios deseados y los niveles de rendimiento.

1.4 Resumen de análisis, arquitectura y diseño de procesos Análisis de redes, arquitectura y diseño son procesos utilizados para producir diseños que son lógico, reproducible y defendible. Estos procesos están conectados, en que la salida de un proceso se utiliza directamente como entrada a la siguiente, creando flujos de información de análisis a la arquitectura y de arquitectura para diseñar. Análisis de red consiste en aprender lo que necesitan los usuarios, sus aplicaciones y dispositivos de la red (Figura 1.2). Se trata también de comprender el comportamiento de la red bajo diferentes situaciones. Análisis de red también define, determina y describe las relaciones entre los usuarios, aplicaciones, dispositivos y redes. En el proceso de análisis de red proporciona la base para las decisiones de arquitectura y el diseño a seguir. El propósito del análisis es doble: primero, escuchar a los usuarios y entender sus necesidades; y segundo, entender el sistema. En el análisis de una red se examinará el estado de la red existente, incluyendo cualquier problema puede tener. Desarrollamos conjuntos de declaraciones de problema Resumen de análisis, arquitectura y diseño de procesos

Estado de la red existente Problemas con red y sistema de Requisitos de los usuarios, aplicaciones, dispositivos de

Descripciones de declaraciones de problema de red Descripciones de requisitos de red Descripciones de los flujos de tráfico Asignaciones de aplicaciones y dispositivos de red Descripciones de riesgos potenciales Figura 1.2 entradas y salidas desde el proceso de análisis de red

y objetivos que describen lo que dirigiéndonos nuestra red destino. Y desarrollar los requisitos y flujos de tráfico, así como asignaciones de usuarios, aplicaciones y dispositivos, en apoyo de nuestras declaraciones de problema y objetivos. Como tal, el análisis de redes nos ayuda a entender cuáles son los problemas que intentamos resolver, y en el proceso recopilar información que se utilizarán en el desarrollo de la arquitectura y el diseño.

Example 1.2. Análisis, arquitectura y diseño de procesos se pueden aplicar a cualquier proyecto de la red, sin importar su tamaño o alcance. Ya que estamos desarrollando conjuntos de declaraciones de problema, los objetivos y requisitos como insumo para el proceso de análisis, podemos escalar la arquitectura y el diseño para cumplir con el alcance del proyecto. Considerar el uso de VPNs del ejemplo 1.1. Podemos desarrollar declaraciones de problema, objetivos y requisitos para VPN en una red existente y desarrollar un análisis, arquitectura y diseño únicamente alrededor de una implementación de VPN.

Arquitectura de red utiliza la información del proceso de análisis para desarrollar una estructura conceptual, alto nivel, end-to-end de la red. En el desarrollo de la arquitectura de red hacemos opciones de tecnología y topología de la red. También determinamos las relaciones entre las funciones de la red (direccionamiento/enrutamiento, gestión de red, rendimiento y seguridad) y cómo optimizar la arquitectura a través de estas relaciones. Generalmente no hay una única arquitectura de "derecha" o diseño de una red; en cambio hay varios que va a trabajar, algunos mejores que otros. Los procesos de arquitectura y diseño se centran en la búsqueda de los mejores candidatos para arquitectura y diseño (optimizado a través de varios parámetros) para sus condiciones de. El proceso de arquitectura de la red determina conjuntos de opciones de tecnología y topología; las clases de equipo necesitado; y las relaciones entre las funciones de red (Figura 1.3). Diseño de redes proporciona física detalle de a la arquitectura. Es el objetivo de nuestro trabajo, la culminación de procesos de análisis y arquitectura. Detalle físico incluye planos y dibujos de la red; selección de proveedores y prestadores de servicios; y selección de equipos (incluyendo los tipos de equipos y configuraciones) (Figura 1.4). Descripciones de declaraciones de problema de red Descripciones de requisitos de red

Descripciones de los flujos de tráfico Asignaciones de aplicaciones y dispositivos a la red las descripciones de los riesgos potenciales

Opciones de tecnología para la red Opciones de topología de red FIGURA 1.3

Relaciones entre clases de equipos de red funciones Entradas y salidas del proceso de arquitectura de red

Selecciones de tecnología para la red Selección de la topología de red Relaciones entre las funciones de red

Selección de proveedor de red Selección de proveedor de red Selección de equipo para red Planos y dibujos de red Figura 1.4 entradas y salidas del proceso de diseño de red

Resumen de análisis, arquitectura y diseño de procesos

Durante el diseño de la red utilizamos un proceso de evaluación para hacer el vendedor, proveedor de servicios y selección de equipo, basado en el análisis de redes y arquitectura de. Aprenderás cómo establecer objetivos de diseño, tales como minimizar los costos de la red o maximizar el rendimiento, así como lograr estos objetivos, a través de mapeo de rendimiento de la red y función de sus objetivos de diseño y evaluación de su diseño contra sus objetivos reconocer Cuando el diseño varía significativamente de estos objetivos. Diseño de red es también sobre la aplicación de las compensaciones, dependencias y restricciones desarrolladas como parte de la arquitectura de red. Ventajas y desventajas, costo versus rendimiento como simplicidad versus función, ocurren durante todo el proceso de diseño, y gran parte del diseño de red refiere a reconocer tales ventajas y desventajas (como interacciones, dependencias y limitaciones) y la optimización de la diseño entre ellos. Como parte del proceso de diseño también aprenderá a desarrollar criterios de evaluación para sus diseños. Como mostramos en el resto de este libro, análisis de redes, arquitectura y diseño se combinan varias cosas: requisitos, tráfico flujos, arquitectura y diseño de objetivos, interacciones, compensaciones, dependencias, restricciones y criterios de evaluación: para optimizar la arquitectura y el diseño de una red en varios parámetros. Estos parámetros son elegidos y analizados durante el proceso de análisis y priorizados y evaluados durante los procesos de diseño

y arquitectura. Al término de estos procesos que se deben tener un conocimiento profundo de la red y un montón de documentación para tomar que enviar a implementación, pruebas e integración.

Example 1.3. Arquitectura y diseño de la red son análogos a la arquitectura y el diseño de una casa. La red y arquitectura página describen los principales componentes funcionales de cada uno (para la red: gestión, direccionamiento y enrutamiento, seguridad y privacidad y rendimiento; la red para el hogar: fontanería, electricidad, climatización [calefacción, vacío, aire acondicionado], framing) y las relaciones entre ellos (de la red: interacciones, dependencias, compensaciones y restricciones; para el hogar: donde cada componente se coloca en relación con los demás). Los diseños de red y la casa también son similares en que ambos proporcionan detalles físicos a la arquitectura. Para la red esto significa donde los dispositivos de red más importantes se encuentran; y, para el hogar, donde se encuentran conductos, enchufes, grifos, desagües y así sucesivamente.

1.4.1 Componentes de proceso de Ahora agregar detalles para el análisis, arquitectura y diseño de procesos. Cada uno de estos procesos tiene acciones que serán tomadas por personal del proyecto y resultados o productos

de cada acción. También es entrada para iniciar el proceso. Así, los procesos se expanden en la figura 1.5. Cada uno de los procesos y la productos tiene componentes que describen acciones específicas o resultados. El conjunto completo de componentes de proceso se muestra en la figura 1.6. Este conjunto de componentes de proceso representa una implementación completa de análisis de redes, arquitectura y diseño y forma la base para el resto de este libro. Algunos de los componentes, sin embargo, pueden ser reducidas en importancia o eliminados

Procesos de la figura 1.5 se muestra con productos y entrada de asociados

Figura 1.6 el conjunto completo de componentes de proceso de

sobre una base por proyecto. A lo largo de este libro que discutiremos qué componentes son necesarios, y que puede ser reducida en importancia.

1.4.2 Importancia táctica y estratégica Análisis de red, la arquitectura y el diseño son parte del proceso de ingeniería que forma la base de proyectos de redes. Estos proyectos tienen inmediata, táctico (corto plazo), y de importancia estratégica (largo plazo) y proyectos de redes deben tener en cuenta todas estas áreas. Te recomiendo que los proyectos de la red tienen un plan que incluya objetivos actuales, a corto plazo y a largo plazo. Mientras que el objetivo actual será un diseño de red, los objetivos a corto plazo y a largo plazo pueden ser mejoras propuestas al objetivo actual, listas de declaraciones del problema, objetivos y requisitos de corto plazo y a largo plazo, o todos ellos. Por ejemplo, la figura 1.7 muestra un plan de proyecto de un año/año/5-años. La idea detrás de este plan es desarrollar un diseño de red que se implementará dentro de un año, nos preparan para los cambios que podamos tenemos que hacer a la red dentro de tres años y se nos mantienen en el sentido de lo que está previsto para cinco años en el futuro. El objetivo a largo plazo (cinco años) es una estimación aproximada. Probablemente no sabremos qué nuevas tecnologías de redes, servicios, niveles de rendimiento estarán disponibles cinco años hacia fuera, ni vamos a saber cómo va a cambiar planes de negocio de nuestros clientes, ni qué problemas red surgen durante ese tiempo. Pero debemos tener una idea de donde queremos estar, con la comprensión que podemos tener para realizar cambios significativos en el objetivo a largo plazo durante los cinco años. Por lo tanto el objetivo a largo plazo es variable.

Figura 1.7 A una- / -/ Plan de proyecto de cinco años

El objetivo actual de (año) debe ser bien entendido y es el foco de nuestro análisis, la arquitectura y el esfuerzo de diseño. Entre los objetivos de un año y cinco años, objetivo a corto plazo (tres años) pretende ser algo flexible, pero se entiende mejor que la meta a largo plazo. Un cambio significativo en el objetivo a largo plazo (por ejemplo, el resultado de una fusión prevista, outsourcing o cambio importante en una empresa) puede estar mediado por correcciones de curso en el plan a corto plazo. Aunque una- /- / a continuación se muestra el plan de cinco años, el concepto importante es que enfoques tácticos y estratégicos de su plan. La experiencia demuestra que una- /- / planes de cinco años son muy buenos puntos de partida, pero dependiendo de sus clientes, rápidamente puede evolucionar su red con un plan de seis-meses/uno-año/dos años, o tener una visión a largo plazo con un plan de uno año/5 años/diez-años. He visto que todos estos planes de trabajo para satisfacer las necesidades de sus clientes.

Example 1.4. Voz sobre IP (VoIP) es de interés para muchas organizaciones y es un ejemplo de un proyecto de red que se beneficiarían de planes tácticos y estratégicos. Si aplicamos el- /- / plan de cinco años antes, el objetivo actual (plan anual) incluye el diseño de red para VoIP, basada en lo que es factible dentro de un año y las declaraciones de problema, objetivos y requisitos que resultan de la proceso de análisis de requisitos. Por ejemplo, el objetivo actual puede ser un diseño que sólo se prepara para VoIP mediante la mejora de la fiabilidad global de la red. El objetivo a corto plazo (plan de tres años) es posible construir en el actual destino agregar o ampliar VoIP a aquellas áreas que pueden apoyarlo. El objetivo a largo plazo (plan quinquenal) abordará los cambios importantes ocurridos en los cuatro años anteriores, incluyendo los avances en la tecnología de VoIP y una evaluación de si continuar con VoIP o evolucionar a nuevas o diferentes tecnologías.

Estos planes pretenden ser iterativo y deben ser regularmente revisados, del orden de dos veces al año, una vez al año o cada dos años, dependiendo de su plan. En cada iteración los objetivos actuales, a corto plazo y a largo plazo se revisan y cotejan con los actuales sistemas de problema declaraciones, objetivos y requerimientos desarrollaron durante el análisis, arquitectura y procesos de diseño. Una iteración del ciclo (incluyendo aceptación, prueba e implementación de red) se muestra en la figura 1.8.

Cada iteración es un paso incremental para los objetivos a corto plazo y a largo plazo, como se muestra en la figura 1.9. Los pasos 1, 2, 3 y 4 corresponden a los pasos en el proceso que se muestra en la figura 1.8. Por lo tanto, cada iteración es un ciclo completo como se muestra arriba. Pasos en proceso de

2

4

Figura 1.8 la naturaleza cíclica e iterativa de los procesos de

Figura 1.9 proceso iteraciones evolucionan hacia el objetivo a largo plazo

1.4.3 Jerarquía y diversidad Todos estos procesos centro alrededor de dos características importantes de las redes: sus niveles de jerarquía y diversidad. Jerarquía es el grado de concentración de redes o flujos de tráfico en puntos de interconexión en la red, así como el número de niveles de puntos de interconexión en la red. En general, como las redes crecen en tamaño y número de usuarios, aplicaciones y dispositivos de aumento, jerarquías proporcionan separación y estructura dentro de la red. Las jerarquías son importantes porque nos ayudan en la determinación de los tamaños de redes, enrutamiento y direccionamiento de configuraciones y la escala de tecnologías de red, rendimiento y niveles de servicio. Un concepto clave de este libro es comprender estas jerarquías, aprender cómo y dónde se producirá y aprender a sacar provecho de ellos.

Junto con la jerarquía, debe ser un examen para el grado de diversidad (también conocido como redundancia o interconexión) en el diseño de la red. Como jerarquía proporciona la estructura de la red, diversidad equilibra esta estructura por la red en los diferentes niveles en el diseño para proporcionar un mayor rendimiento a través de la red de interconexión. La diversidad es importante en que proporciona un mecanismo para lograr el rendimiento dentro de una estructura jerárquica. La dinámica entre la jerarquía y diversidad es tal vez una de las desventajas fundamentales en diseño y arquitectura de red, y demuestra para arriba varias veces en el análisis, arquitectura y procesos de diseño. Jerarquía y diversidad pueden ser un poco confusos en este punto, pero este concepto se hará más claro a medida que avance a través del libro. La jerarquía es fundamental ya que proporciona una separación de la red en segmentos de red (como lo es en toda la naturaleza). Estos segmentos pueden ser separadas, más pequeñas redes (subredes) o dominios de difusión. La jerarquía es necesaria cuando la cantidad de tráfico en la red crece más allá de la capacidad de la red o cuando las interacciones entre dispositivos de la red provocan congestión (por ejemplo, tormentas de broadcast). Figura 1.10 ilustra los niveles de jerarquía y diversidad de una red. Se trata de una estructura típica para una red, con los círculos que representan las redes o enrutadores y líneas que representan los enlaces de comunicaciones entre redes o enrutadores. En esta figura hay cuatro niveles de jerarquía, de redes de núcleo (o columna vertebral) para redes de acceso más cercano a los usuarios. Tenga en cuenta que los puntos finales de este árbol (comúnmente conocida como hojas; representan la final redes, dispositivos o usuarios) ocurren en el mismo nivel de jerarquía. Esto no tiene que ser el caso; de hecho, en la mayoría de las redes hay deja a más niveles de jerarquía. Un ejemplo de la adición de jerarquía a la red está cambiando de un plano (puente o capa 2 Switch) estructura a una estructura de enrutado. Esto se puede hacer para reducir el tamaño del dominio de difusión o el número de dispositivos en un mensaje de difusión. Adición de enrutamiento a la red de un dominio de difusión en un número de dominios de broadcast más pequeños, y los flujos de tráfico se concentran en los enrutadores. Figura 1.11 muestra este escenario. Jerarquía se añade también a las redes cuando evoluciona desde

Figura 1.10 jerarquía y diversidad de una red

Figura 1.11 jerarquía añadido a una red

un sistema autónomo solo (AS) culo múltiples de conexión, así como al migrar de los protocolos de Gateway Interior (IGP) a los protocolos de Gateway Exterior (EGP) y enrutamiento basado en políticas. Una red de distribución de contenido (CDN) es un ejemplo de añadir diversidad a una red. Una CDN omite el núcleo de una red, donde la congestión es más probable que ocurra, y que conecta directamente los dispositivos o redes inferiores en la jerarquía (Figura 1.12). Esto ofrece un rendimiento mejor y más previsible, pero también puede afectar a la jerarquía de la red modificando su comportamiento de enrutamiento.

Red jerárquica

CDN se agrega, conectividad directa entre redes, pasando por alto la jerarquía y ofrece mejor rendimiento Figura 1.12 diversidad añadido a una red

1.4.4 Importancia del análisis de red Se enfatiza la importancia del análisis de red en este libro porque la experiencia ha demostrado que red personal encontrar valiosísima — una vez que están convencidos de su importancia. Toma de análisis de trabajo, y cuando sabes que habrá una recompensa, es más proclives a hacer ese trabajo. En este libro usted aprenderá cómo recopilar y analizar requisitos de red y flujos de tráfico. Requisitos de la red son las solicitudes de las capacidades en la red, generalmente en términos de rendimiento y función, que son necesarios para el éxito de esta red. Requisitos de la red pueden ser reunidos y derivados de los clientes, aplicaciones y dispositivos. Tales requisitos son fundamentales para la arquitectura y el diseño de la red porque forman la base para las expectativas del cliente y la satisfacción. Requisitos, conjuntamente con las mediciones en la red existente (si existe), se utilizan para derivar los flujos de tráfico (sistemas de tráfico de red que tienen algunos atributos comunes, como direcciones origen/destino, tipo de información, enrutamiento u otros información end-to-end). Análisis de estos flujos imparte información direccional sobre requisitos y ubicación. Aquí es donde requisitos de funcionamiento y arquitectura comienzan a converger y a menudo es el punto en estos procesos donde uno puede empezar a ver donde "hot spots"-puntos focales para el rendimiento de la red — aparecerán en la red. Como veremos, evaluar los riesgos de seguridad es también parte del proceso de análisis.

Resultados del proceso de análisis, los requisitos y especificaciones de flujo, entonces se utilizan como entrada para el diseño y la arquitectura de red. En el desarrollo de la arquitectura de red, un número de arquitecturas de componentes, dirigidos a funciones concretas de la red, es evaluado. Arquitecturas de componente deseado se combinan en la arquitectura de referencia, que proporciona una vista de alto nivel de su red. Esta vista de alto nivel luego se detalla físicamente durante el proceso de diseño de la red. Análisis de redes es importante que nos ayuda a comprender la complejidad y los matices de cada red y los sistemas que apoyan. Análisis también proporciona datos que se toman decisiones diferentes, y estos datos pueden y deben ser documentados como parte de una pista de auditoría para los procesos de diseño y arquitectura. Estos datos ayudan a garantizar que la resultante de la arquitectura y el diseño son defendibles. Red de conocimiento y complejidad del sistema En general, las redes y los sistemas que apoyan se están volviendo cada vez más complejos. Parte de esta complejidad radica en la sofisticación de las capacidades proporcionadas por esa red. Consideremos, por ejemplo, qué servicios pueden ser incorporados en una red de vanguardia actual. Infraestructura planeación de capacidad, que a menudo incluye sobre ingeniería de tráfico, puede ser ampliada para incluir soporte para aplicaciones con limitaciones de retardo y puede contener una variedad de capacidad y mecanismos de control de retrasos, como tráfico, calidad de servicio de múltiples niveles en la red, acuerdos de nivel de servicio a los servicios de pareja a los clientes y las políticas para gobernar y aplicar el servicio en toda la red. (Tenga en cuenta que calidad de servicio se refiere a determinar, establecer y actuar en niveles de prioridad para los flujos de tráfico. A el is an informal or formal contract between a provider and user that defines the terms of the provider’s responsibility to the user and the type and extent of accountability if those responsibilities are not met. Finally, service-level agreement policies are high-level statements about how network resources are to be allocated among users.) Analysis of these mechanisms—how they work and interoperate—is covered in detail later in this book. Complejidad de la red y el sistema es no lineal. Optimización de la red debe tener en cuenta que compiten y a menudo conflictivas necesidades. Además, varios grupos con diferentes ideas y deseos (por ejemplo, usuarios, gerencia corporativa, personal de la red) influyen en el diseño de la red. La red está diseñada ya sea por Comisión o a través de un enfoque sistemático que los grupos pueden estar de acuerdo. Las redes han evolucionado para incorporar capacidades más sofisticadas. Redes (primera generación) tempranas centran en soportar conectividad básica entre dispositivos y sobre cómo ampliar las redes para apoyar a un número creciente de usuarios (por ejemplo, divide en segmentos redes mediante puentes o enrutadores). Redes de segunda generación se centraron en interoperabilidad para ampliar el alcance y la escala de redes que permite conexiones entre múltiples redes dispares. Actualmente estamos en la etapa en la evolución de la red donde la prestación de servicios es importante para el éxito de los usuarios y sus aplicaciones. Esta etapa puede considerarse la tercera generación de redes. Figura 1.13 ilustra las distintas generaciones de las redes y sus interacciones. Estamos empezando a ver los pasos hacia las capacidades de próxima generación, como rudimentario de la toma de decisiones dentro de la red. Puede esperarse que los componentes de la red evolucionará para convertirse en auto configurable y manejable, especialmente para aquellas redes que deben ser configuradas o administradas por los usuarios finales (por ejemplo, teletrabajadores, usuarios de servicios de movilidad/portabilidad). De hecho, será necesario la

complejidad y funcionamiento del aumento de redes y servicios ofrecidos por las redes a ser más sofisticadas. Las redes de rejilla son un claro paso en esta dirección. Usuarios, aplicaciones y dispositivos también están desarrollando capacidades más sofisticadas. Un ejemplo de esto es la dinámica entre la jerarquía y diversidad que puede verse en la Internet actual. Como aplicación y dispositivo tráfico flujos evolucionan para incorporar información en cuanto a calidad, rendimiento y costo (por ejemplo, en tiempo real

Figura 1.13 generaciones de redes

medios de transmisión), se espera que estas características pueden usarse para asegurar caminos a través de Internet que entrega alto rendimiento o calidad del tráfico. Jerarquía en Internet obliga a menudo a los flujos de tráfico a través de caminos nonoptimal, cruzando varios culo con diferentes características de performance y servicio, obstaculizando la entrega de alto rendimiento, alta calidad. Figura 1.14 muestra a una jerarquía de múltiples niveles de redes de núcleo (o backbone) proveedores de redes para proveedores de acceso a la red. Los flujos de tráfico entre los usuarios finales pueden viajar a través de varios niveles de esta jerarquía.

Figura 1.14 jerarquía y el flujo de tráfico

Figura 1.15 diversidad añadido para mejorar el rendimiento de los flujos de tráfico seleccione

Para contrarrestar el impacto de la jerarquía, se puede introducir diversidad en Internet en puntos estratégicos, proporcionando accesos directos que partes de la Internet. El resultado es que, para algunos flujos de selección, trazados están optimizados para entrega alto rendimiento, alta calidad (Figura 1.15). La dinámica entre la jerarquía y diversidad existe en todas las redes hasta cierto punto, y parte del proceso de análisis es la determinación de dónde y cómo aplicarlo. En la figura 1.15 se agregan conexiones entre redes en el mismo nivel de jerarquía, en esencia, proporcionando un acceso "directo" o "bypass" alrededor de parte de la Internet, lo que resulta en mejores características de rendimiento. Este concepto de la adición de diversidad para mejorar el rendimiento por senderos selectos puede aplicarse fácilmente a redes de la empresa. Análisis nos ayuda a entender cómo influyen en tecnologías de redes, usuarios, aplicaciones y dispositivos (y viceversa). Esto es importante para medir cómo los usuarios de la red se adaptarán a la red, que afecta el ciclo de vida total de la red. Consideremos, por ejemplo, la evolución de los protocolos de enrutamiento, que se muestra en la figura 1.16. Aunque el protocolo de información de enrutamiento (RIP), un protocolo de Gateway de Interior (IGP) desplegados como parte de las primeras versiones de TCP/IP, era simple y fácil de usar, sus limitaciones se destacaron como redes ampliadas para dar cabida a grandes grupos de usuarios (grupos de trabajo) y incluso los grupos de las redes (sistemas autónomos [culo]). Enrutamiento de tecnología adaptada mediante la adición de jerarquía de encaminamiento, en términos de nuevos IGPs como abierto más corto camino primero (OSPF), así como en el desarrollo de protocolos de Gateway Exterior (EGP) como frontera Gateway protocolo (BGP), que puede acomodar jerarquía en grupos de redes (como jerarquía). Este proceso continúa hoy en día como las políticas de alto nivel se introducen para controlar

Figura 1.16 evolución enrutamiento

enrutamiento en un nivel superior IGP o EGP y BGP4 presenta a jerarquía a través de la agrupación de routers de BGP4 en confederaciones. Se discuten en detalle en la arquitectura de direccionamiento y enrutamiento protocolos de enrutamiento (ver capítulo 6). Del mismo modo, los usuarios, aplicaciones y dispositivos también influyen en su entorno. Como dispositivos, aplicaciones y nuevo, actualizados o diferentes usuarios se agregan a una red, pueden cambiar los requisitos de esa red. El proceso de análisis debe examinar equipo como HighEnd y servidores de aplicaciones, almacenamiento de datos, análisis y archivística y especializados específicas del entorno dispositivos como PDAs, cámaras de vídeo o equipos médicos afectan la red. Finalmente, el proceso de análisis nos ayuda a entender las fuerzas y los cambios en el trabajo dentro del sistema (red y sus usuarios, aplicaciones y dispositivos). Las redes son altamente dinámicas, cambiando el resto del sistema y ser cambiado por el sistema. Algunos de los factores que conducen al cambio en el sistema de incluyen comportamiento de uso y patrones; Qué, cómo, dónde y cuándo afecta a cada usuario del sistema; la aparición de nuevas capacidades, por ejemplo, conmutación óptica, más unidades de procesamiento central (CPU) y memoria más barato; y cambios en el alcance y la escala del medio ambiente, y consolidación y outsourcing. Arquitectura y diseño Defensibility Una parte importante (y a menudo pasado por alto) de análisis de red es la documentación que proporciona información sobre la toma de decisiones en la red de procesos de diseño y arquitectura. Durante el proceso de análisis Estamos recopilando datos que pueden utilizarse para determinar qué arquitectura y decisiones de diseño es necesario, detalles de cada decisión (incluyendo razones de cada decisión), las dependencias entre las decisiones y cualquier fondomaterial utilizado para llegar a estas decisiones. Datos de análisis de red, junto con las decisiones hechas durante el proceso, pueden ser documentados para formar un pistas de auditoría , es decir, el conjunto de decisiones, para la arquitectura y el diseño, datos y documentos. Pistas de auditoría son útiles para describir y defender una arquitectura de red particular o diseño. Una dirección de auditoría trail ayuda a preguntas como "¿por qué elegiste esa tecnología?" "¿Por qué no esta nueva red rinda como se espera?" o "¿por qué esta red costó tanto?" Tener documentado el análisis de la red existente, los problemas a abordar, requisitos para la nueva red y todas las decisiones con respecto a esa red, usted podrá contestar preguntas en cualquier momento sobre su nueva red.

Decisiones con respecto a la arquitectura de red y el diseño deben ser defendible desde varias perspectivas: técnica, para poder abordar cualquier desafío técnico contra su arquitectura y diseño; presupuestario, para garantizar que los costos de la red dentro del presupuesto o para justificar por qué un presupuesto se ha superado; calendario, para asegurar que se cumplan los plazos de desarrollo, instalación, pruebas y operaciones; y recursos, tales como personal o equipos, para asegurar que el cliente tiene todo lo necesario para construir y operar esta red. Una auditoría también es útil como un documento histórico sobre la red. Con el tiempo, después de que la red se hace operativa, nuevo personal de la red puede revisar este documento para entender la lógica detrás de lo que fue diseñada la red. Idealmente, este documento debe ser periódicamente revisado, con nueva información añadida sobre los cambios a la red. Así, una pista de auditoría se convierte en una historia para esa red. La experiencia demuestra que el conjunto de documentos, datos y decisiones en una pista de auditoría puede ser vital en la toma de decisiones de diseño táctico día a día durante todo el proyecto. La inversión en el tiempo en esta fase del proyecto puede ahorrar grandes cantidades de tiempo y recursos en el proyecto. La Web es una gran herramienta a utilizar en la construcción de una pista de auditoría. Porque una pista de auditoría contiene información sobre la antigua red, la nueva red y las decisiones tomadas acerca de la nueva red, esta información fácilmente accesible por los usuarios de la red hace mucho sentido. Poner dicha información en páginas Web internas permite un fácil acceso por todo el mundo, y cambios o adiciones a la pista de auditoría pueden verse inmediatamente. Aunque puede haber cierta información que su cliente no puede todo el mundo para ver, como los resultados de un análisis de riesgo, más información generalmente puede ser accesible a todos. Para obtener información que está restringida (necesidad de saber), pueden utilizarse páginas Web ocultadas y protegida por contraseña. Por supuesto, al poner información sensible en un lugar común, como un sitio Web, se debe proporcionar suficiente seguridad contra ataques externos (hackers). Una pista de auditoría puede ser desarrollada utilizando herramientas de software de hoja de cálculo y procesador de textos estándar, y herramientas de software especializan para este propósito están disponibles. Declaraciones del problema, objetivos, requisitos, las decisiones y todos los datos de fondo se introducen en la pista de auditoría y toda la información es tiempo de estampado. Ejemplos de información de pista de auditoría se presentan más adelante en este libro.

1.4.5 Modelo de análisis de redes, arquitectura y diseño Redes tradicionalmente ha tenido poca o ninguna base en el análisis o desarrollo arquitectónico, con los diseñadores a menudo depender de tecnologías que sean más familiar para ellos o son nuevos, populares o sugeridas por los proveedores o consultores. Hay serios problemas con este enfoque tradicional. En particular, puede tomar decisiones sin la debida diligencia de análisis o desarrollo arquitectónico, y estas decisiones, especialmente las realizadas durante las primeras fases del proyecto, están desinformadas. Como resultado, no puede ser una pista de auditoría para la arquitectura y el diseño; y por lo tanto, la arquitectura y el diseño no pueden ser defendibles. Además, dicho arquitectura/diseño pueden carecer de coherencia en su enfoque tecnológico. Falta de datos de análisis y arquitectura, no podemos tener una base para hacer comparaciones de la tecnología y ventajas y desventajas. Y

lo más importante, sin la adecuada recopilación de requisitos y análisis, no podemos estar seguros si nuestra red satisfaga las necesidades de sus usuarios. Por lo tanto, la red de análisis, arquitectura y el diseño son fundamentales para el desarrollo de una red. Análisis de redes, arquitectura y diseño son similares a otros procesos de ingeniería en que tratan los siguientes aspectos: • Definir los problemas a abordar • Establecer y administrar las expectativas del cliente • Monitoreo de la red, sistema y su entorno • Análisis de datos • Desarrollo de un conjunto de opciones para resolver problemas • Opciones de evaluación y optimización basan en diversas ventajas y desventajas • Seleccionar una o más opciones • Planificación de la implementación

Definir los problemas a abordar debe implicar una rápida evaluación del proyecto y medio ambiente — en esencia, realizar una cordura Compruebe en la tarea, así como determinar el tamaño y el alcance de los problemas, determinar que se trabaja en el derecho problemas y comprobación de los niveles de dificultad previsto en las tecnologías, posibles arquitecturas y diseños, administración, gestión y política en ese entorno. Como tamaño de los problemas que enfrentan en este proyecto, usted debe comenzar a estimar el nivel de recursos necesarios (por ejemplo, presupuesto, horario, personal). También debe desarrollar su propia visión de los problemas que afectan a ese entorno. Usted puede encontrar que, desde su análisis de la situación, la definición de los problemas puede diferir de la definición del cliente. Dependiendo de hasta qué punto aparte son las definiciones, puede que necesite ajustar las expectativas de sus clientes sobre el proyecto. Example 1.5. Una vez, en la realización de un análisis de red de área metropolitana de un cliente (hombre), me di cuenta que el problema era que no lo pensaban en los clientes. Pensaron que la tecnología elegida en aquel momento, servicio de datos multimegabit conmutado (SMDS) y el protocolo de enrutamiento (OSPF) no funcionaban correctamente juntos. Sin embargo, el problema realmente fue que el personal de la red se había olvidado de conectar cualquiera de sus redes de área local para el hombre. Por supuesto, cuando se corrieron las pruebas de una LAN a otra, se pasaron no hay datos. Era un problema fácil de solucionar, pero mucho trabajo pasamos cambiando la visión del cliente sobre el problema y las expectativas de lo que debía hacerse. Originalmente el cliente quiso cambiar proveedores para los equipos de enrutamiento y reemplazar el servicio SMDS. Finalmente, estaban convencidos de que el equipo y el servicio estaban bien y que el problema era interno a la organización. Aunque Duns ya no está ampliamente disponible, su comportamiento como una tecnología de (no difusión NBMA) acceso múltiple de no emisión es similar a otras tecnologías disponibles actualmente.

Una primera parte de cada proyecto es determinar cuáles son las expectativas de su cliente y ajustar estas expectativas en consecuencia. La idea aquí es no dar falsas expectativas a los clientes y hacerles tener expectativas irreales, porque esto lleva a dificultades más adelante en el proyecto. Por el contrario, el objetivo es proporcionar una vista exacta y realista de los problemas técnicos en la red y lo que se necesita para resolverlos. Las expectativas de clientes centrarán probablemente en presupuesto, horario y personal pero también pueden incluir sus comentarios sobre tecnologías y metodologías. Y, a veces, política se incrustan dentro del proyecto y debe ser tratada. La clave aquí es para separar técnica de temas no técnicos y centrarse en las cuestiones técnicas y recursos. Parte de determinar las expectativas de los clientes significa entender lo que quieren hacer con su red de clientes. Esto puede implicar entender el cliente modelo de negocios y operaciones. Además, el cliente puede esperar tener una entrada importante en el desarrollo de la red. Como establecer las expectativas del cliente, deberá establecer las líneas de comunicación entre el grupo de arquitectura y diseño de red, administración, usuarios y personal de red. Al establecer cuáles son las expectativas del cliente, puede que necesite ajustar y administrar estas expectativas. Esto puede hacerse por identificar ventajas y desventajas y opciones de recursos, tecnologías, arquitecturas y diseños y luego presentar y discutir ventajas y desventajas y opciones con su cliente. Traer a clientes en el proceso y trabajar con ellos para tomar decisiones críticas acerca de la red les ayudará a sentirse cómodo con el proceso. Si una red existente forma parte de este proyecto, supervisando en esta red, así como de otras partes del sistema y su entorno, puede proporcionar información valiosa sobre el comportamiento actual de los usuarios, aplicaciones y dispositivos y sus requerimientos para el nuevo red. Monitoreo también puede validar las definiciones de su cliente de los problemas con la red existente. Cuando es posible monitorear la red, usted tendrá que determinar qué datos desea recopilar (basado en lo que quiere lograr con los datos), recogen cualquier lugares estratégicos en la red donde usted quiere recoger estos datos y la frecuencia y duración de los datos ion. En este punto del proceso debe tener varios conjuntos de información con la que usted puede comenzar su análisis de la red. Pueden tener datos históricos de la administración de la red; datos capturados durante el monitoreo; requisitos de los usuarios, personal y administración; definición del cliente del problema; y su definición. Todos estos datos se utilizan en el análisis de la red, de los cuales hay tres partes: Análisis de requerimientos o necesidades, análisis de flujo y un análisis de riesgo (seguridad). Información en estos análisis se puede colocar en página interna del cliente, como se mencionó anteriormente, aunque cierta información (por ejemplo, los resultados de los análisis de riesgos) puede tener que se mantienen en privado. Resultados de los análisis de red se utilizan en los procesos de diseño y arquitectura, donde se desarrollan conjuntos de opciones, incluyendo posibles arquitecturas, diseños, topologías, tecnologías, hardware, software, protocolos y servicios. Estos conjuntos de opciones de continuación son evaluados para determinar las soluciones óptimas para los problemas. Criterios necesitan ser desarrollados durante el análisis, arquitectura y diseño de procesos para evaluar estas opciones. Junto con estos criterios, utilizará los resultados de los análisis de red, incluyendo requisitos, ventajas y desventajas y las dependencias entre las opciones.

Una metodología de sistemas

Haber seleccionado una o más opciones, puede completar la arquitectura de red y el diseño y preparación para aplicación. En este punto usted puede considerar la elaboración de un plan de proyecto para determinar el calendario, presupuesto y recursos, así como hitos mayores y menores, puestos de control y comentarios.

1.5 Una metodología de sistemas Comenzamos el proceso de análisis de red con un debate sobre el enfoque de la metodología de sistemas a las redes. Aplicando una metodología de sistemas para análisis, arquitectura y diseño de la red es un enfoque relativamente nuevo, especialmente en el mundo de Internet protocolo (IP). Metodología de sistemas (que se aplican a redes) significa ver la red que son arquitectura y diseño, junto con un subconjunto de su entorno (todo lo que la red interactúa con o impactos,) como un sistema. Asociados con este sistema son conjuntos de servicios (niveles de funcionamiento y la función) que se ofrecen por la red para el resto del sistema. Este enfoque considera la red como parte de un sistema más grande, con interacciones y dependencias entre la red y sus usuarios, aplicaciones y dispositivos. Como se verá, la metodología de sistemas revela interesantes conceptos que se utilizan a lo largo de este libro. Uno de los conceptos fundamentales de la metodología de sistemas es que los diseños y arquitecturas de red tienen en cuenta los servicios que cada red va a proporcionar y apoyar. Esto refleja la creciente sofisticación de las redes, que han evolucionado de proporcionar conectividad básica y el funcionamiento de reenvío de paquetes para ser una plataforma para diversos servicios. Como comentamos anteriormente, estamos en la etapa en la evolución de la red donde los servicios son importantes para el éxito de muchas redes (redes de tercera generación). Algunos ejemplos de redes de tercera generación son el proveedor de servicios de redes que soportan niveles de rendimiento y precios a sus clientes, redes de distribución de contenido que se especializan en el transporte de alto rendimiento, y las redes de empresa que incorporar y aplicar modelos de uso y la facturación a sus clientes. Cuando una red se ve como parte de un sistema que presta servicios, la metodología de los sistemas funciona bastante bien para una variedad de redes, desde pequeñas y simples a las redes grandes y complejas. Ayuda a determinar, definir y describir las características importantes y las capacidades de su red.

1.6 Descripción del sistema A sistema de es un conjunto de componentes que trabajan juntos para apoyar o proveer conectividad, comunicaciones y servicios a los usuarios del sistema. Genéricamente hablando,

Figura 1.17 componentes genéricos de un sistema de

componentes del sistema son los usuarios, aplicaciones, dispositivos y redes. Aunque los usuarios del sistema pueden considerarse fuera del sistema, también tienen requisitos que incluyen como parte del sistema. A lo largo de este libro se incluyen los usuarios como parte del sistema. Figura 1.17 muestra cómo se conectan estos componentes dentro del sistema. Figura 1.17 muestra los componentes genéricos de un sistema. Estos componentes se pueden subdividir, si es necesario, para centrarse en una parte particular del sistema. Por ejemplo, los usuarios en una red corporativa podrían describirse más como red y ordenador personal, así como desarrolladores y clientes de productos de la Corporación. En un sentido similar, aplicaciones pueden ser genérica o específica a un determinado usuario, cliente o grupo, genérico a una base de clientes, en toda la red. Si tuviéramos que comparar esta visión de un sistema con el modelo de protocolo de interconexión (OSI) de sistema abierto, se vería como la figura 1.18. Tenga en cuenta que, en esta comparación, se modifican algunas de las capas OSI. Esto es para mostrar que puede haber varias capas de protocolo en uno de los niveles del sistema. Por ejemplo, el físico de los OSI, enlace de datos y capas de red pueden estar presentes en los dispositivos y también pueden estar presentes varias veces en el nivel de red (por ejemplo, en los conmutadores y enrutadores en la red). Figura 1.19 muestra que los dispositivos se pueden subdividir por clase para mostrar funciones especializadas, tales como almacenamiento, computación o servidores de aplicaciones, o un dispositivo individual puede subdividirse para mostrar su sistema operativo (SO), controladores de dispositivos, hardware periférico, o interfaz de programación de aplicaciones (API). Todos estos componentes trabajan juntos para proporcionar conectividad y comunicaciones a través de la red, entre los usuarios, aplicaciones y dispositivos. La conectividad y las comunicaciones pueden ser adaptados para satisfacer las necesidades específicas de los usuarios y Descripción del sistema

Aplicación Usuario Presentación Período de sesiones

Aplicación

Transporte

Red Enlace de datos

Dispositivo de

Física

Red Figura 1.18 comparación de capas OSI de niveles del sistema

Figura 1.19 dispositivo componente separado en componentes

aplicaciones, tales como entrega en tiempo real de voz o medios de transmisión, entrega de mejor esfuerzo de datos no interactivos o entrega confiable de datos de misión crítica. El grado de detalle utilizado para describir los componentes del sistema es una relación inversa entre la cantidad de detalle y exactitud que desea en la descripción y cuánto tiempo y esfuerzo que está dispuestos a poner en él. Si usted es el arquitecto de red responsable de una red corporativa, puede invertir tiempo y recursos en desarrollar una descripción detallada de los componentes de su sistema, mientras que un consultor o Ingeniero de diseño del proveedor tenga poco tiempo y recursos gastar en tal descripción. Es importante tener en cuenta, sin embargo, que incluso una pequeña cantidad de tiempo invertido aquí pagará dividendos más adelante en el proceso de análisis.

Figura 1.20 visión tradicional de un sistema de

La visión tradicional de un sistema había centrado en la red proporciona conectividad entre los dispositivos (Figura 1.20) y típicamente no consideran los usuarios o aplicaciones. Este punto de vista tradicional de un sistema no es suficientemente completa para las redes de hoy. En particular, tenemos que incluir a los usuarios y sus aplicaciones en la descripción del sistema. La experiencia demuestra que este grado de carácter descriptivo en el sistema (usuarios, aplicaciones, dispositivos y redes) es generalmente suficiente para proporcionar una descripción completa y exacta de la mayoría de los sistemas de acceso general, pero no tan grande como para ser abrumadora a la red el arquitecto. (General-acceso a es un término para describir el acceso común de los usuarios a aplicaciones de computación y recursos de almacenamiento en una red.) Dentro de este sistema, los usuarios representan los usuarios finales o clientes del sistema. Estos usuarios finales son los destinatarios finales de los servicios de red compatibles con el sistema. Una de las razones para la identificación de los componentes del sistema es entender cómo estos interfaz de componentes uno con el otro en los límites del componente. Definiendo Cuáles son los componentes del sistema, también estamos estableciendo lo que es de esperarse a través de cada interfaz. Por ejemplo, usando el estándar (los usuarios, aplicaciones, dispositivos y redes), figura 1.21 muestra interfaces posibles.

Figura 1.21 ha añadido un sistema genérico con Interfaces

Descripción del servicio

Aunque la descripción del sistema en la figura 1.21 es generalmente satisfactoria para el inicio de la mayoría de arquitecturas de red, puede haber ocasiones cuando desea describir más componentes o han definido más interfaces. Por ejemplo, la interfaz de dispositivo de la red

puede ser simple o compleja, dependiendo de lo que está tratando de lograr. Para una red que proporcionará conectividad simple, la interfaz de dispositivo de red puede ser una interfaz de LAN estándar (por ejemplo, Ethernet 100BaseT) sin priorización ni selección de virtual LAN (VLAN 802.1p/q). Para una red que ofrece más que la simple conectividad, tales como la calidad del servicio, la interfaz de dispositivo de la red puede acoplarse más de cerca con el dispositivo o aplicación. Esto se puede lograr mediante el uso de controladores que porciones de la pila de protocolos y APIs que pueden interpretar requerimientos de performance de la aplicación. Aunque la descripción del sistema es un intento de identificar los componentes a través de todo el sistema, tenemos que reconocer que la mayoría de los sistemas no es totalmente homogénea y que componentes pueden cambiar de varias partes del sistema. Esto ocurre generalmente en las partes del sistema que realizan funciones específicas, tales como una red de dispositivos específicos (por ejemplo, una red de distribución de vídeo) o una red de área de almacenamiento (SAN). Por ejemplo, aunque una SAN se puede describir como el conjunto (los usuarios, aplicaciones, dispositivos y redes), los usuarios pueden ser otros dispositivos en el sistema, y puede ser la única aplicación para almacenamiento y archivo.

1.7 Descripción del servicio El concepto de servicios de red en este libro se basa en el trabajo de servicios de la Internet Engineering Task Force (IETF). Esta organización ha venido desarrollando la descripción de los servicios de redes IP. En general, consideran servicios de red conjuntos de capacidades de red que pueden ser configuradas y administradas dentro de la red y entre redes. Aplicamos este concepto a la red de análisis, arquitectura y diseño, integración de servicios en todo el sistema. Esto le ayudará a aprovechar el concepto de servicios mediante el análisis, arquitectura y diseño basan en servicios, y también le preparará para el futuro cercano, cuando servicios será configurable y manejable dentro de la red. Servicios de red , o servicios, se definen aquí como niveles de rendimiento y función en la red. Esto podemos verlo desde dos perspectivas: como servicios que se ofrecen por la red con el resto del sistema (dispositivos, aplicaciones y usuarios) o como conjuntos de requisitos de la red que se esperan por los usuarios, aplicaciones o dispositivos. Niveles de rendimiento son descritos por la capacidad de características de rendimiento, retraso y RMA (confiabilidad, mantenibilidad y disponibilidad), mientras que las funciones se describen como seguridad, contabilidad, facturación, programación y (y otros). Esto se describe con más detalle en la sección siguiente. Es importante tener en cuenta que el concepto de los servicios utilizados en este libro se basa en lo que redes pueden proporcionar al sistema. Es por lo tanto, no debe ser confundido con servicios que otras partes del sistema (por ejemplo, aplicaciones) pueden ofrecer uno al otro (por ejemplo, servicios de procesamiento de gráficos). Cuando el término servicio de se utiliza en este libro, es en referencia a servicio de red. Servicios de red en la mayoría de redes actuales se basan en la entrega de mejor esfuerzo (impredecible y poco confiable). Además de entrega de mejor esfuerzo, examinamos algunos nuevos tipos de servicios, incluyendo de alto rendimiento predecible (estocásticos o probabilísticos) y garantía de servicios. Estos nuevos servicios requieren algunas maneras diferentes de mirar las redes, y usted verá cómo incorporar estos servicios en su arquitectura y diseño. También miramos rendimiento solo nivel y de nivel múltiple en la red y mostrar cómo

distinguir entre ellos y cómo se relacionan con a mejor-esfuerzo, predecible y servicios garantizados. Servicios de red son jerárquicos, y características de cada servicio pueden agruparse a las descripciones de alto nivel de forma de un servicio, como se muestra en la figura 1.22.

... Bajo retardo)

Características de servicio para cada nivel de servicio Característica 1Delay característica (e.g., 100 ms) Característica 2Capacity característica (por ejemplo, 10 Mb/s) Característica característica del 3RMA (e.g., 99.99% Uptime)... Característica de la seguridad (por ejemplo, encriptación) Características utilizadas para configurar servicios en retardo de ida y vuelta de red, retardo de extremo a extremo y como servicio de métricas para medir y verificar ServicesCapacity, rendimiento, utilización del Goodput Buffer/cola Niveles de prioridad

Figura 1.22 agrupar características en los niveles de servicio y descripciones

1.8 Características del servicio Análisis de uno de los objetivos de la red debe ser capaz de caracterizar servicios que diseñaron en la red y compraron a proveedores y prestadores de servicios (por ejemplo, a través de las solicitudes de información [RFI], cita [PDP] o [convocatoria], propuesta de documentos utilizados en el proceso de adquisición). Características del servicio son rendimiento de red y parámetros funcionales que se utilizan para describir servicios. Estos servicios son ofrecidos por la red para el sistema (el servicio que ofrece) o solicitados por los usuarios, aplicaciones o dispositivos de la red (la solicitud de servicio). Características de los servicios que se solicitan de la red también se pueden considerar requisitos para esa red. Ejemplos de gama de las características del servicio de estimación de los requerimientos de capacidad basados en información anecdótica o cualitativa acerca de la red para elaboradas listados de diferentes capacidad de demora y requisitos de RMA, por usuario, aplicación o dispositivo, junto con requisitos de seguridad, manejabilidad, facilidad de uso, flexibilidad y otros.

Example 1.6. Ejemplos de características de servicio son: • Definir un nivel de privacidad para un grupo de usuarios o de una organización o seguridad • Capacidad máxima de proporcionar 1.5 Mb/s a un usuario remoto •

Garantizar un máximo retardo ida y vuelta de 100 ms a servidores de una granja de servidores

Tales requisitos son útiles en la determinación de la necesidad del sistema de servicios en el suministro de entrada a la arquitectura de red y el diseño y en la configuración de servicios de dispositivos de red (routers, switches, sistemas operativos). Las mediciones de estas características en la red para supervisar, verificar y gestionar servicios se llaman métricas de servicio. En este libro nos centramos en desarrollar requerimientos de servicio de la red y utilizar esas características para configurar, supervisar y verificar los servicios dentro de la red. Para los servicios a ser útiles y eficaces, deben describirse y provisioning end-to-end en todos componentes entre puntos de demarcación bien definida de la red. "End-to-end" no significa necesariamente solamente de dispositivo de un usuario a dispositivo de otro usuario. Se puede definir entre las redes de los usuarios a los servidores, o entre dispositivos especializados (Figura 1.23). Cuando los servicios no son con provisioning end-to-end, algunos componentes no sean capaces de soportar y así los servicios

Figura 1.23 ejemplo demarcaciones puntos para describir End-to-End dentro de una red

No. Los puntos de demarcación determinan donde end-to-end en la red. Determinar estos puntos de la demarcación es una parte importante de describir un servicio. Servicios también deben ser configurables, medibles y verificables dentro del sistema. Esto es necesario para asegurar que los usuarios finales, aplicaciones y dispositivos están recibiendo los servicios han solicitado (y posiblemente han estado pagando para), y esto lleva a la contabilidad y facturación de recursos del sistema (incluida la red). Usted verá cómo métricas de servicio se pueden utilizar para medir y verificar los servicios y sus características. Servicios también suelen ser jerárquicos dentro del sistema, tipos de servicio diferentes y mecanismos aplicados en cada capa en la jerarquía. Por ejemplo, figura 1.24 muestra una jerarquía de calidad de servicio (QoS) que se centra en el tráfico

Figura 1.24 un ejemplo de jerarquía de servicio dentro de una red

transporte en el núcleo de la red colocando servicios específicos en la red de acceso cerca de los usuarios finales, aplicaciones y dispositivos.

1.8.1 Niveles de servicio Características del servicio pueden agruparse para formar uno o más niveles de servicio de la red. Esto se hace para hacer servicio de aprovisionamiento más fácil en que puede configurar, administrar, cuenta y cuenta de un grupo de características de servicio (nivel de servicio) en lugar de un número de características individuales. Por ejemplo, un nivel de servicio (por ejemplo, premium) puede combinar capacidad (por ejemplo, 1,5 Mb/s) y confiabilidad (uptime de 99.99%). Niveles de servicio también son útiles en facturación y contabilidad. Esta es una vista de proveedor del servicio de la red, donde se ofrecen servicios a los clientes (usuarios) por una tarifa. Este punto de vista de las redes es cada vez más popular en redes de la empresa, desplazando a la vista de redes como puramente la infraestructura de centros de costos. Hay muchas formas de describir los niveles de servicio, incluyendo relé comprometido información tasas de fotogramas (CIRs), que son niveles de capacidad; clases de servicio (CES), que combinan características de retardo y capacidad; y el IP tipo de servicio (ToSs) y calidades de servicio (QoSs), que priorizan el tráfico para el tráfico acondicionado funciones que se describen en la arquitectura de rendimiento (ver capítulo 8). También pueden ser combinaciones de los mencionados mecanismos, así como los niveles de servicio personalizado, basado en grupos de características de servicio individual. Estas combinaciones dependen de que la tecnología de red, protocolo, mecanismo o combinación está proporcionando el servicio. Figura 1.25 servicio ofertas, solicitudes y métricas se muestran aplicadas al sistema. En este ejemplo se muestra una demarcación de servicios entre los componentes de red y dispositivo. Según el requisito de servicio o característica, sin embargo, demarcación también puede ser entre los componentes del dispositivo y aplicación.

Métricas, ofertas y solicitudes de servicio Figura 1.25

Example 1.7.

Vino de A petición de un cliente que cada edificio debe tener capacidad de Fast Ethernet (FE) para el resto de la red. Como parte del análisis de requisitos, esta petición se convirtió en un requisito para la capacidad máxima de 100 Mb/s de los usuarios en cada edificio. Esto solicitud de servicio fue luego acompañado en los procesos de diseño y requisitos de una opción de tecnología que podría cumplir o exceder la solicitud. En este caso FE fue elegido como la tecnología, y la oferta de servicios fue de 100 Mb/s para cada edificio. Métricas de servicio luego fueron agregadas, que consiste en medir las conexiones de FE de la IP switch o router en cada edificio a la red troncal.

Servicios y niveles de servicio pueden distinguirse por sus grados de previsibilidad o determinismo. En la siguiente sección se discute la entrega de mejor esfuerzo, que no es predecible o determinista, como previsible y garantizada. Servicios y niveles de servicio también se distinguen por sus grados de rendimiento. Verá cómo la capacidad de las características de rendimiento de servicio demora y RMA se utilizan para describir los servicios y niveles de servicio.

1.8.2 Componentes del sistema y servicios de red Servicios de red se derivan de los requisitos en cada uno de los componentes en el sistema. Son end-to-end (entre los puntos finales que se definen) dentro del sistema, describiendo lo que se espera de cada componente. Requerimientos de servicio de la red que estamos construyendo se derivan de cada componente. Puede haber requisitos de usuario, requisitos de uso, requisitos del dispositivo y requisitos (existente) de la red. Ya que estamos construyendo el componente de red, cualquier requisito del componente de la red proviene de las redes existentes que incorporan o conectarse a la nueva red. Requisitos de componentes se añaden uno a otro, ser refinado y ampliado como la red viene más cerca de ser realizado. Necesidades de los usuarios, que son los más subjetivos y generales, refinados y ampliados por requisitos de la aplicación de componente, que son a su vez refinado y ampliado por los componentes de red y dispositivo. Por lo tanto, requisitos filtran abajo de usuario de aplicación en el dispositivo a la red, dando como resultado un conjunto de necesidades que pueden ser configuradas y administradas en los dispositivos de red se. Esto resulta en una oferta de servicios de extremo a extremo, que consiste en las características del servicio que se configuran en cada dispositivo de red en el camino (routers, switches, hubs). Como en la figura 1.26, características de servicio son configuradas y gestionadas dentro de cada uno Necesidades de los usuarios (p. ej., retraso de interacción) Requisitos de la aplicación (por ejemplo, aplicación procesamiento de retardo) Requisitos del dispositivo (p. ej., retraso de End-to-End de máximo) Requisitos de la red (p. ej., retraso de End-to-End de máximo) Requisitos de elemento de red (por ejemplo, tamaños de búfer o las prioridades)

Figura 1,26 requisitos de flujo componentes de usuario a red

elemento en las interfaces entre los elementos. Estos servicios son más específicas y tienen el alcance más pequeño (típicamente un dispositivo de red). Definición de servicios de red y métricas de servicio ayuda a mantener el funcionamiento del sistema y puede proporcionar un valor adicional o comodidad a los usuarios y sus aplicaciones. Mediante la definición de métricas de servicio estamos determinando se mide en la red, que nos ayudará en la gestión y monitorización de red. Recordar que los servicios de red son sistemas de funcionamiento y la función, por lo que los requisitos también pueden incluir funciones de uno de los componentes. Funciones ejemplos de red de monitoreo y gestión, seguridad y contabilidad. Servicios como estos deben considerarse parte integral de la arquitectura de red y el diseño. En este libro, seguridad (y privacidad) y gestión de red cada uno tiene sus propias arquitecturas. Esto puede parecer obvio, pero tradicionalmente, los servicios como la red de seguridad y gestión han sido ideas de arquitectura y diseño, a menudo olvidado en la arquitectura hasta que surgen problemas.

Example 1.8. La ruta de red que se muestra en la figura 1.27 se diseñó para optimizar el rendimiento entre los usuarios y sus servidores. La gráfica en la parte inferior de la figura es una estimación de la capacidad total prevista en cada segmento del camino. En esta red un paquete sobre SONET (POS) enlace en la OC-48 nivel (2.544 Gb/s) conecta dos routers, que luego se conectan a conmutadores Gigabit Ethernet (GigE). Servidores

GigE GigE usuario PC

(4) interruptor de (100)

10

1

0.1 Distancia a lo largo de la trayectoria de transmisión Figura 1.27 la capacidad en cada punto de la trayectoria de transmisión antes de la adición de una seguridad Cortafuegos

Después de que se implementó, un firewall de seguridad fue agregado en de LAN los usuarios (con interfaces de FE), sin ser considerada parte de los análisis, arquitectura o diseño original. El resultado fue que el firewall cambió las características de capacidad en todo el camino reduciendo rendimiento de procesamiento entre el PC del usuario y el switch GigE, como se muestra en la figura 1.28.

Servidores GigE Router Router GigE seguridad FE usuario PC (4) interruptor interruptor de Firewall (100)

10 1 0.1 Distancia a lo largo de la trayectoria de transmisión Figura 1.28 la capacidad en cada punto de la trayectoria de transmisión después de la adición de una seguridad Cortafuegos

De nuestra arquitectura y diseño de objetivos es identificar esos cuellos de botella de rendimiento antes de implementa la red. Teniendo en cuenta seguridad, administración de redes, servicios y enrutamiento y abordar en el proceso de análisis, somos mucho más propensos a comprender su comportamiento y su efecto en ellos y con la red. Por lo tanto somos capaces de arquitecto de la red para adaptarse a sus requisitos y la interoperabilidad. Cuando las características del servicio se aplican a dispositivos de red, como routers, switches, unidades de servicio de datos (DSU) y así sucesivamente, algunas de estas características pueden ser específica del proveedor. En este libro nos centramos en aquellas características que forman parte de estándares públicos y no de proveedor específico. Es importante señalar aunque las características basadas en estándares están "estandarizadas" sobre la base de que sus descripciones públicamente disponibles (por ejemplo, a través de un IETF RFC), sancionada por una organización reconocida por la comunidad de redes, o en general aceptada y usada como un estándar de facto, la aplicación de características está abierta a interpretación y a menudo varía a través de proveedores y de plataformas de proveedores.

1.8.3 Requisitos y solicitudes de servicio Requisitos y solicitudes de servicio, en parte, destacan por el grado de previsibilidad que necesitan del servicio por el usuario, la aplicación o el dispositivo que hace la solicitud. Basado en su predictibilidad, solicitudes de servicio se clasifican como el mejor esfuerzo, previsible y garantizado. Requisitos y solicitudes de servicio también pueden ser apropiados para el funcionamiento de nivel único o múltiple para una red. Servicio de mejor esfuerzo significa que no hay ningún control sobre cómo la red va a satisfacer la solicitud de servicio, que no hay ninguna garantía asociada a este servicio. Tales peticiones indican que el resto del sistema (usuarios, aplicaciones y dispositivos) tendrán que adaptarse al estado de la red en un momento dado. Así, el servicio para dichas solicitudes será impredecible y poco fiable, con un rendimiento variable en un rango de valores (de la red están disponibles para el mínimo común denominador del rendimiento a través de todas las tecnologías en la path-to-end). Dichas solicitudes de servicio o tienen no hay requisitos de funcionamiento de la red o se basan únicamente en las estimaciones de capacidad. Cuando los requisitos son no específicos,

rendimiento de la red no puede ajustarse para satisfacer cualquier exigencia particular de usuario, aplicación o dispositivo. Servicio garantizado es lo contrario del servicio de mejor esfuerzo. Donde el servicio de mejor esfuerzo es impredecible y poco confiable, servicio garantizado debe ser predecible y confiable a tal grado que, cuando el servicio no está disponible, el sistema es rendir cuentas. Un servicio garantizado implica un contrato entre el usuario y el proveedor. Durante períodos cuando el contrato se rompe (por ejemplo, cuando el servicio no está disponible), el proveedor debe explicar la pérdida de servicio y, posiblemente, compensar adecuadamente al usuario. Con servicios de mejor esfuerzo y garantizadas en los extremos opuestos del espectro de servicio, muchos servicios caen en algún lugar entre. Estos son servicios predecibles, que requieren cierto grado de previsibilidad (más de mejor esfuerzo) pero no requieren la responsabilidad de un servicio garantizado. Servicio garantizado y predecible pide se basan algunos a priori conocimiento y control sobre el estado del sistema. Dichas solicitudes pueden requerir que el servicio funciona como era de esperarse o limita. Por lo tanto, tales servicios deben tener un conjunto claro de requisitos. De la red a disposición recursos para apoyar un servicio predecible o garantizado, los requisitos de servicio de esa solicitud deben ser configurable, medibles y verificables. Esto es donde se aplican las solicitudes de servicio, ofertas y métricas. Tenga en cuenta que hay veces cuando un servicio puede ser mejor esfuerzo, predecible o garantizada, dependiendo de cómo se interpreta. Por lo tanto, es importante entender la necesidad de un buen conjunto de requisitos ya que estas ayudarán a determinar los tipos de servicios para planificar. Además, aunque el término previsible se encuentra en una zona gris entre lo posible y garantizada, es el tipo de servicio probablemente ser servido por la mayoría de los mecanismos de funcionamiento, como vemos en el capítulo 8. Por ejemplo, suponga que un dispositivo requiere capacidad (ancho de banda) entre 4 y 10 Mb/s. Debe haber una manera de comunicar esta petición a través de la red, una manera de medir y obtener el nivel de recursos necesarios para apoyar esta petición, una manera de determinar si los recursos necesarios están disponibles y un método para controlar el flujo de información y recursos para mantener este servicio entre 4 y 10 Mb/s de red. Capacidad (ancho de banda) es un recurso finito dentro de una red. Por ejemplo, el rendimiento de una conexión de 100 Mb/s FE entre dos routers está delimitado por esa tecnología. Si fuéramos a mirar el tráfico fluye a través de que conexión de 100 Mb/s, veríamos que, para un servicio de mejor esfuerzo común, capacidad sería distribuida a través de todos los flujos de tráfico. Como corrientes más fueron agregadas a este respecto, los recursos se extendería hacia fuera hasta que, en algún momento, se produce congestión. Congestión perturbarían los flujos de tráfico a través de esa conexión, que afectan a los protocolos y aplicaciones para cada flujo. Lo clave aquí es que, en términos de asignación de recursos, todos los flujos de tráfico tienen cierto acceso a los recursos. Esto se muestra en la figura 1.29. En esta figura la capacidad disponible (curva punteada) disminuye a medida que el número de aumentos de los flujos de tráfico. En consecuencia, la carga en la red (curva maciza) de todos los aumentos de los flujos de tráfico. Sin embargo, en algún momento congestión afecta la cantidad de tráfico de usuario por la conexión y rendimiento de la conexión (curva pesada) gotas. Como congestión interfiere con el transporte end-to-end de tráfico, retransmitirá algunos protocolos (por ejemplo, TCP)

Figura 1.29 el rendimiento de una conexión Ethernet rápida bajo condiciones de esfuerzo

tráfico. La diferencia entre la carga y las curvas de rendimiento es debido a las retransmisiones. Esto no es deseable, para mientras se carga la conexión, sólo un porcentaje de que la carga se entregan con éxito a los destinos. En algún momento todo el tráfico en ese sentido podría ser debido a las retransmisiones y rendimiento acercaría a cero. Este enfoque se utiliza en redes de mejor esfuerzo. En contraste, considere una red de telefonía tradicional. Las llamadas se realizan en esta red, y los recursos se asignan a cada llamada. Llamadas más se añaden a la red, en el punto donde todos los recursos han sido asignados, se les niega llamadas adicionales. Las llamadas de salida en la red no puedan sufrir ninguna degradación de rendimiento, pero no hay llamadas nuevas se permitieron hasta que los recursos están disponibles. Control de admisión de llamadas(CAC) es un mecanismo para limitar el número de llamadas en una red, de tal modo controlando la asignación de recursos. Esto se muestra en la figura 1.30. Llamadas individuales se muestran en esta figura, y cada llamada es de 10 Mb/s para la simplicidad. Como cada llamada es aceptada, los recursos se asignan, por lo que la disponibilidad disminuye y aumenta la carga para cada llamada. Cuando se agoten los recursos, no se permiten más llamadas. La congestión no es un problema para las llamadas existentes y se maximiza el rendimiento. Este enfoque es similar a un servicio garantizado. Existe una relación inversa entre estos dos enfoques para la asignación de recursos en una red. Aunque una red mejor esfuerzo permite el acceso a todos los flujos de tráfico como sea posible, puede ocurrir degradación del rendimiento a través de todos los flujos de tráfico. Control de la admisión conserva recursos para flujos de tráfico que ya se han asignado recursos pero se niegan los flujos de tráfico adicional cuando se agoten los recursos.

Figura 1.30 el rendimiento de una conexión Fast Ethernet en CAC

En muchas redes se desea ambos enfoques (o un híbrido entre ellos). Por ejemplo, una voz sobre servicio del IP (VoIP), que proporciona un servicio de telefonía a través de una red de datos, algunas de las características de CAC requiere mientras opera sobre una red de mejor esfuerzo. Estos enfoques híbridos se analizan en detalle en el capítulo 8. Servicio de solicitudes y requisitos también pueden ser bajos o alto rendimiento en términos de capacidad, demoras y RMA. Bajo y alto rendimiento requisitos dependen de cada red en particular. Un requisito es bajo o alto rendimiento en relación con otros requisitos de esa red. Bajo rendimiento es un indicador de que la solicitud de servicio o las características de rendimiento de requisito son inferiores a un umbral de rendimiento determinado para esa red. Asimismo, el alto rendimiento es un indicador de que la solicitud de servicio o las características de rendimiento de requisito están mayores que un umbral de rendimiento determinado para esa red. Así, en la determinación de baja y de alto rendimiento para una red, vamos a desarrollar uno o más umbrales de performance para esa red. Rendimiento de nivel múltiple indica que hay múltiples niveles de rendimiento para esa red. Requisitos de funcionamiento de la solo-grada son aproximadamente equivalentes dentro de una red.

Tenga en cuenta que actuaciones bajas y altas no se describen en términos de servicio de mejor esfuerzo previsible y garantizada ya que son independientes unos de otros. Best-effort, previsiblesy garantizados servicio se refieren al grado de previsibilidad de una solicitud o requerimiento, mientras que baja y altas prestaciones se refieren a un nivel de desempeño relativo para esa petición o requerimiento. Por ejemplo, una red puede ser enteramente mejor esfuerzo (son redes más actuales), sin embargo, a menudo podemos distinguir bajo requisitos de alto rendimiento de dicha red. Y cuando una red tiene regiones de bajo y alto rendimiento para la capacidad de demora y RMA, puede ser predecible o requerimientos de cada región. Por su naturaleza, cada servicio tiene asociado un conjunto de requisitos. Estos requisitos se basan en los niveles de rendimiento y función deseada por el usuario, aplicación o dispositivo que solicita servicio. Requisitos de funcionamiento se describen en términos de capacidad, demoras y RMA, mientras que los requisitos funcionales describen funciones específicas necesarias en el servicio, como multidifusión, seguridad, administración o contabilidad. Utilizamos las solicitudes para el funcionamiento y la función en el desarrollo de la arquitectura de red y el diseño — por ejemplo, al describir el nivel general de desempeño necesarios en la red. Como se mencionó anteriormente, requisitos de desempeño de servicio (capacidad de demora y RMA) pueden agruparse, formando uno o más niveles de servicio. Por ejemplo, una solicitud de servicio puede acoplar una capacidad específica (por ejemplo, 1,5 Mb/s) con un límite de retraso end-to-end (por ejemplo, 40 ms). A veces, dichos niveles de servicio pueden asignarse a los mecanismos de servicio bien conocido como relais del marco CIR o ToS del IP o QoS. Así, los niveles de servicio son una forma de mapa de rendimiento y exigencias funcionales a una oferta de servicios de red conocida o estándar. Un servicio debidamente especificado proporciona visión en la cual deben medirse características de rendimiento en la red para verificar la prestación de servicios.

1.8.4 Ofertas de servicio Solicitudes de servicios que son generadas por los usuarios, aplicaciones y dispositivos son compatibles con los servicios ofrecidos por la red. Estas ofertas de servicio (por ejemplo, a través de relevo de estructura CIR o ToS del IP o QoS, mencionado en la sección anterior) son las contrapartes de la red a las peticiones de usuario, aplicación y dispositivo de servicio. Oferta de servicios se asignan a las solicitudes de servicio y así también puede ser categorizado como el mejor esfuerzo, previsible y garantizado. Ofertas de servicio de mejor esfuerzo no son predecibles, están basados en el estado de la red en un momento dado. Hay poco o ningún conocimiento previo sobre el rendimiento, y no hay ningún control sobre la red en cualquier momento. Mayoría de las redes hoy en día funciona en modo best-effort. Un buen ejemplo de una red que ofrece un servicio de mejor esfuerzo es la actual Internet. Ofertas de servicio de mejor esfuerzo son compatibles con las solicitudes de servicio de mejor esfuerzo. La oferta de servicios ni la petición asume ningún conocimiento sobre el estado de o el control sobre la red. La red ofrece cualquier servicio está disponible en ese momento (normalmente sólo disponible ancho de banda), y el resto del sistema adapta al flujo de información para el servicio disponible (por ejemplo, a través de control de flujo TCP).

Example 1.9.

Un ejemplo de una solicitud de servicio de mejor esfuerzo y la ofrenda es una transferencia de archivos (por ejemplo, usando FTP) en Internet. FTP usa TCP como su Protocolo de transporte, que se adapta, mediante un mecanismo de control de flujo de slidingwindow, para aproximar el estado actual de la red está en funcionamiento a través. Así, el requisito de servicio de FTP sobre TCP es mejor esfuerzo, y el correspondiente servicio de Internet es el mejor esfuerzo. El resultado es que, cuando la sesión FTP está activa, las características de rendimiento de la red (Internet) y control de flujo (windows TCP) están constantemente interactuando y adaptación, así como lidiar con otras sesiones de aplicación de recursos de la red. Además, como parte del servicio de TCP para las aplicaciones que soporta, proporciona libre de errores, transmisión de datos confiable.

Ontheotherhand, predictableandguaranteedserviceofferingshavesomedegree de previsibilidad o se limita. Para lograrlo, tiene que haber algún conocimiento de la red, junto con el control sobre la red, con el fin de cumplir con los límites de prestaciones o garantías. Tales servicios deben ser medibles y verificables. Sólo porque un servicio es predecible o garantizada no implican necesariamente que también es de alto rendimiento. Tomemos, por ejemplo, la red telefónica. Ofrece servicio predecible pero bajo rendimiento (en términos de capacidad). Para apoyar conversaciones de voz, esta red debe ser capaz de apoyo demora bastante estricta y tolerancias de la variación del retardo, a pesar de la capacidad por sesión del usuario (llamada telefónica) es relativamente pequeño, o bajo rendimiento. Qué es conocida desde una perspectiva de telefonía es algo nuevo en el mundo actual de redes de datos. Apoyo estricto retraso y variación de retardo es uno de los aspectos más difíciles del diseño y arquitectura de red de datos. Ofertas de servicio garantizado y previsible deben ser compatibles con sus correspondientes solicitudes de servicio. En cada caso, requisitos de desempeño de servicio (capacidad de demora y RMA) en una solicitud de servicio se traducen en las características de rendimiento correspondiente en la oferta de servicios.

Example 1.10. Un ejemplo de una solicitud de servicio predecible y la oferta se aprecia en una red diseñada para soportar flujos en tiempo real de datos de telemetría. Una meta de arquitectura y diseño para una red de apoyo de telemetría en tiempo real es la capacidad de especificar retardo de extremo a extremo y tienen la red satisfacer esta petición de demora. Una corriente de telemetría en tiempo real debe tener un requisito de retardo de extremo a extremo, y este requisito formarían la base para la solicitud de servicio. Por ejemplo, esta solicitud de servicio puede ser un retraso de end-to-end de 25 ms, con una variación del retardo de ±400 s. Esto constituiría la solicitud y el nivel de servicio (es decir, un nivel de QoS) que necesita ser apoyado por la red. La red entonces sería diseñada y diseñada para soportar un nivel de QoS de 25 ms retardo de extremo a extremo y una variación del retardo de ±400 s. retardo y variación de retardo sería medido y verificado con mediciones de servicio en el sistema, tal vez por entonces utilizando utilidades comunes como TCPdump (una utilidad de captura de información TCP) ping (una utilidad común para la medición de retardo de ida y vuelta), o mediante una aplicación personalizada.

Utilizamos varios métodos para describir los requisitos de rendimiento del servicio y características dentro de una red, incluyendo los umbrales, límites y garantías. También nos enseña a distinguir entre alto y bajo rendimiento para cada proyecto de la red.

Este enfoque no significa que el servicio de mejor esfuerzo es inherentemente de bajo rendimiento o que servicios predecibles o garantizados son de alto rendimiento. Más bien, significa que previsibilidad en servicios es una característica importante y de rendimiento. Hay veces cuando una red está mejor diseñada para el servicio de mejor esfuerzo y otras veces cuando se necesitan servicios de mejor esfuerzo, previsibles y garantizados. Vamos a ver que cuando se requieren servicios predecibles o garantizados en la red, consideración para esos requisitos tiende a conducir la arquitectura y el diseño en una dirección, mientras que el examen para el servicio de mejor esfuerzo lleva en otra dirección. Es la combinación de todos los servicios que ayuda a hacer la arquitectura y el diseño completo.

1.8.5 Métricas de servicio Para que requerimientos de performance del servicio y características ser útil, deben ser configurables, medibles y verificables en el sistema. Por lo tanto, se describen requisitos de rendimiento y características en términos de métricas de servicio, que pretenden ser configurable y medibles. Porque métricas de servicio deben ser cantidades mensurables, puede utilizarse para medir los umbrales y los límites de servicio. Los umbrales y los límites se utilizan para distinguir si el rendimiento está en conformidad (cumple) o no conformidad (supera) con un requerimiento de servicio. Un umbral es un valor para una característica de rendimiento que es una frontera entre dos regiones de conformidad y, cuando se cruzaron en una o ambas direcciones, va a generar una acción. Un límite es una frontera entre las regiones de conformes y disconformes y se toma como un límite superior o inferior para una característica de rendimiento. Cruzar un límite es más grave que cruzando un umbral, y la acción resultante es generalmente más grave (por ejemplo, dejando caer paquetes para llevar el rendimiento a conformidad). Por ejemplo, se puede definir un umbral para distinguir entre bajo y alto rendimiento para un servicio particular. Nivel bajo y alto rendimiento es conformes con el servicio, y el umbral se utiliza para indicar cuando se cruza el límite. Este umbral puede ser medido y monitoreado en la red, provocando alguna acción (por ejemplo, un intermitente rojo en la consola de administrador) cuando se cruza este umbral. Un ejemplo de esto puede ser medir el retardo de ida y vuelta de un camino. Un umbral de ms N se aplica a esta medida. Si los tiempos de ida y vuelta superan N ms, una alarma es generada en una estación de administración de red. Discutimos esto en mayor detalle en el capítulo de arquitectura de administración de red (capítulo 7). De manera similar, se pueden crear límites con métricas de servicio para proporcionar límites superior e inferior en una cantidad medida. Cuando se cruza un límite, el tráfico se considera no conforme (supera los requisitos de funcionamiento), y se toman medidas para devolver el tráfico de la conformidad (por ejemplo, por retrasar o dejar caer los paquetes). Figura 1.31 muestra cómo límites y umbrales pueden ser aplicados en el sistema. En esta figura, un umbral de 6 Mb/s es la frontera entre baja y alta performance para un requerimiento de servicio y un límite de 8 Mb/s es la frontera entre la conformidad y no conformidad de ese servicio. Cuando tráfico cruza el umbral de 6 Mb/s, una advertencia se envía a la gerencia de la red (con un cambio de color de verde a amarillo). Estos avisos pueden utilizarse para la tendencia de análisis de la red, por ejemplo, para determinar cuándo la capacidad debe ser

Figura 1.31 rendimiento límites y umbrales

Características de rendimiento

actualizado. Cuando tráfico cruza 8 Mb límite de s, la red adopta medidas para reducir la capacidad utilizada por ese flujo de tráfico y una alerta se envía a administración de redes (con un cambio de color de amarillo a rojo) hasta la capacidad de nivel cae por debajo de 8 Mb/s y otra vez es conforme. Los umbrales y los límites son útiles aplicaciones de métricas de servicio para entender y controlar los niveles de rendimiento en la red, apoyo a los servicios.

1.9 Características de rendimiento Servicios pueden incluir uno o más de las características que hemos mencionado hasta ahora en este capítulo: capacidad, retardo y RMA. Cada característica es realmente una etiqueta para una clase de características de ese tipo. Por ejemplo, el término capacidad se utiliza como una etiqueta para la clase de las características que implica mover información de un lugar a otro, incluyendo ancho de banda, rendimiento, goodput y así sucesivamente. Del mismo modo, el retraso es una etiqueta para la clase de características que incluye el extremo final demora, retardo de ida y vuelta y variación del retardo. RMA es una etiqueta para la clase de características que incluye la confiabilidad, mantenibilidad y disponibilidad. Así, cuando se utilizan los términos capacidad, retrasoy RMA en este libro, puede utilizar otros términos de cada clase, dependiendo de su red. Hay veces en que hace más sentido para describir la capacidad en términos de rendimiento, por ejemplo, en el desarrollo de requerimientos para aplicaciones. Retardo de ida y vuelta se utiliza comúnmente como medida de retraso, aunque a veces requisitos de retardo se expresan en términos de retardo unidireccional.

1.9.1 Capacidad Capacidad es una medida de la capacidad del sistema para transferir información (voz, datos, video o combinaciones de éstos). Varios términos se asocian con la capacidad, tales como ancho de banda, rendimiento, o goodput. Aunque utilizamos el término genérico capacidad a lo largo de este libro para hacer referencia a esta clase de características, puede usar otro término en lugar de o junto con la capacidad.

Example 1.11. El ancho de banda de un SONET OC - 3c enlace es 155.52 Mb/s, que es tres veces el ancho de banda de un OC-1 link (51,84 Mb/s). Este ancho de banda no incluye el protocolo de enlace de datos, red o capa de transporte (por ejemplo, SONET, IP o protocolo de datagrama de usuario protocolo transporte control [TCP/UDP]) encima de la cabeza o en el caso de redes de área amplia, la pérdida de rendimiento debido a la anchura de banda × producto de la demora en la red. Cuando una red o elemento está funcionando en su capacidad teórica, se dice que se presentará en velocidad de línea. Cuando un OC - 3c circuito fue probado, los valores de capacidad realizable (rendimiento) oscilaron entre aproximadamente 80 y 128 Mb/s (mediciones en la capa de transporte [TCP] de la investigación nacional y red de educación [NREN] y aerodinámica numérica Redes de simulación [NAS], NASA Ames Research Center, marzo de 1996).

1.9.2 Retardo de Demora es una medida de la diferencia de tiempo en la transmisión de información a través del sistema. En su sentido más básico, el retardo es la diferencia de tiempo en la transmisión de una sola unidad de información (bit, byte, célula, marco o paquete) de fuente a destino. Como con la capacidad, hay varias maneras de describir y medir el retraso. También hay varias fuentes de retraso, tales como propagación, transmisión, cola y el proceso. Retraso se puede medir en una dirección (end-to-end) y en ambas direcciones (ida y vuelta). Ambas mediciones de retardo extremo a extremo e ida y vuelta son útiles; sin embargo, retrasos sólo ida y vuelta se pueden medir con el uso de la utilidad práctica y universalmente disponible ping. Otra medida de retraso incorpora dispositivo y proceso de aplicación, teniendo en cuenta el tiempo para completar una tarea. A medida que aumenta el tamaño de una tarea, los tiempos de procesamiento de las aplicaciones (y así el tiempo de respuesta del sistema) también aumentan. Este tiempo de respuesta, aquí denominado latencia, puede dar información importante sobre el comportamiento de la aplicación y la red. Latencia puede utilizarse también para describir el tiempo de respuesta de un dispositivo de red, como la latencia a través de un switch o router. En este caso el tiempo de procesamiento es de ese switch o router. Variación del retardo, que es el cambio en la demora en el tiempo, es una característica importante para aplicaciones y flujos de tráfico que requieren retraso constante. Por ejemplo, aplicaciones en tiempo real y tiempo real requieren a menudo variación de retardo estricto. Variación de retardo es también conocido como inquietud. Juntos, retardo (end-to-end e ida y vuelta), latencia y variación del retardo ayudan a describir el comportamiento de la red.

1.9.3 RMA

RMA se refiere a la confiabilidad, mantenibilidad y disponibilidad. Fiabilidad es un indicador estadístico de la frecuencia de falla de la red y sus componentes y representa las paradas no programadas del servicio. Es importante tener en cuenta Características de rendimiento

que sólo fallas que impiden que el sistema de realización de su misión, o fallas de missioncritical (más sobre esto en el capítulo 2), generalmente se consideran en este análisis. Fallas de componentes que no tienen efecto sobre la misión de, al menos cuando ellos fallan, no son considerados en estos cálculos. Falla de un componente espera necesita tiende a pero no es un fracaso de misión crítica. Fiabilidad también requiere cierto grado de comportamiento predecible. Para que un servicio para ser considerado confiable, la entrega de información deberá producirse dentro de los límites de tiempo conocido. Cuando los tiempos de entrega varían grandemente, los usuarios pierden confianza en la entrega oportuna de la información. En este sentido que el término confiabilidad pueden acoplarse con confianza en describe cómo los usuarios tienen confianza que la red y el sistema cumplirá con sus requisitos. Puede verse un paralelo con la industria aérea. Pasajeros (usuarios) del sistema de línea aérea esperan precisa entrega de la información (en este caso los pasajeros ellos mismos) al destino. Perder o extraviar a pasajeros es inaceptable. Además, también se espera la entrega predecible. Pasajeros esperan que los vuelos que parten y llegan dentro de los límites de tiempo razonables. Cuando estos límites se traspasan, pasajeros están probables que utilice una compañía aérea diferente o no volar en todos. Del mismo modo, cuando se utiliza una aplicación, el usuario espera un tiempo de respuesta razonable desde la aplicación, que depende de la oportuna entrega de información a través del sistema. Es junto con fiabilidad mantenibilidad. Mantenibilidad es una medida estadística del tiempo a restaurar el sistema a estado operacional después de que ha experimentado una falla. Esto se expresa generalmente como una tiempo-para-reparación (MTTR). Reparación de un fallo del sistema consiste en varias etapas: detección; aislamiento de la falta de un componente que puede ser reemplazado; el tiempo requerido para entregar las piezas necesarias para la ubicación del componente fallido (tiempo de logística); el tiempo para realmente cambiar el componente, probarlo, y restaurar el servicio completo. Tiempo medio de reparación generalmente asume que el logística el tiempo es cero; se trata de una hipótesis, que no es válido si un componente debe ser sustituido para restaurar el servicio tarda días en obtener. Para describir completamente a esta clase de rendimiento, añadimos la disponibilidad de fiabilidad y mantenibilidad. Disponibilidad de (también conocido como operacional) es la relación entre la frecuencia de fallos críticos y el momento de restaurar el servicio. Se define como el tiempo medio entre fallos críticos (o tiempo medio entre fallos) dividido por la suma del tiempo medio de reparación y el tiempo promedio entre fallas críticas o tiempo medio entre fallos. Estas relaciones se muestran en la siguiente ecuación, donde A es la disponibilidad. A=(MTBCF)/(MTBCF+MTTR) o A=(MTBF)/(MTBF+MTTR)

Capacidad, retardo y RMA dependen entre sí. Por ejemplo, el énfasis de un diseño de red puede ser obligado retraso: un sistema que soporta transacciones de punto de venta puede necesitar garantizar la entrega de información al cliente y completar la transacción dentro de 15 segundos (donde el retardo de red en el orden de 100s de ms); una aplicación Web puede tener requisitos similares. Sin embargo, en una aplicación de computación intensiva seamos capaces de optimizar el sistema de búferes de datos durante los períodos de la informática. En este caso, demora no puede ser tan importante como una garantía de la eventual entrega. Por otra parte, un sistema que soporta visualización de operaciones bancarias en tiempo real puede requerir un retardo ida y vuelta de menos de 40 ms, con una variación de retardo de menos de 500 s. Si se exceden estos límites de retraso, la tarea de visualización falla para esa aplicación, forzando el sistema a utilizar otras técnicas.

1.9.4 Sobres de rendimiento Requisitos de rendimiento se pueden combinar para describir una gama de rendimiento para el sistema. Un envolvente de desempeño es una combinación de dos o más requisitos de desempeño, con umbrales y los límites superiores o inferiores para cada uno. Dentro de este sobre, se trazan los niveles de aplicación, dispositivo o requisitos de funcionamiento de la red. Figuras de 1.32 y 1.33 muestran dos tales sobres. El rendimiento

Figura 1.32 un ejemplo de una envoltura de rendimiento 2D

Soporte de red

Figura 1.33 un ejemplo de una envoltura de rendimiento 3D

envolvente en la figura 1.32 se compone de capacidad, en términos de tamaños de datos transferidos a través de la red y el retardo de extremo a extremo. En esta figura, se muestra demora como 1 retraso de consistencia. Figura 1.33 es un envolvente de rendimiento 3D, demostrando capacidad, retardo y RMA. Este sobre también describe dos regiones de funcionamiento, bajo y de alto rendimiento, que son funciones de los límites y los umbrales de capacidad, retardo, y RMA. Sobres de rendimiento tales como éstos son útiles para la visualización de las regiones de retraso, la capacidad y la RMA en que la red se espera operar basada en requisitos para esa red. En el capítulo 2 discutimos cómo se desarrollan los requisitos para una red.

1.10 Soporte de red La capacidad del cliente de mantener el nivel requerido de rendimiento (que diseñó y diseñado en la red) sobre el ciclo de vida de la red es un espacio de networking que a menudo se descuida. Es

un error asumir que una red exitosa arquitectura y diseño los requisitos solamente en el día que se entrega al cliente y que las necesidades futuras son responsabilidad del cliente. La experiencia indica operaciones y soporte constituyen el 80% de los costes de ciclo de vida de un sistema, considerando que el desarrollo, adquisición e instalación representan sólo el 20%. Buena red de arquitectos y diseñadores tienen en cuenta los principales factores que afectan la operatividad y capacidad de soporte como que tomar sus decisiones. Clientes bien informados insisten en que comprende las operaciones y apoyo las implicaciones de una arquitectura de red y el diseño. A veces, estas cuestiones pueden ser de más preocupación que la viabilidad de una nueva tecnología. Las postimplementation fases del ciclo de vida de la red se pueden romper en tres elementos: operaciones, mantenimiento y conocimiento humano. El elemento de operaciones se centra en garantizar que la red y el sistema están operados y administrados correctamente y que se identifican las acciones de mantenimiento requerido. El elemento de mantenimiento se centra en el mantenimiento preventivo y correctivo y las piezas, herramientas, planes y procedimientos para llevar a cabo estas funciones. El elemento de conocimiento humano es el conjunto de documentación, capacitación y personal especializado para operar y mantener la red y el sistema. Decisiones de diseño afectan a cada uno de estos factores y tienen un impacto directo en la capacidad del cliente de mantener el alto nivel de servicio originalmente realizado tras la implementación de la red. No considerar el soporte en el análisis, arquitectura y diseño de procesos tiene una serie de graves consecuencias. En primer lugar, un cliente inteligente, ante un arquitectura/diseño de red que obviamente no puede ser operado o mantenido por su organización, rechazar el proyecto de la red o se niegan a pagar por ello. En segundo lugar, un cliente que acepta el diseño de la arquitectura y la posterior aplicación tendrá recursos insuficientes para responder a las interrupciones de red y sistema, rendimiento inaceptable después de un período de tiempo y puede sufrir efectos adversos en su operación o negocio (por ejemplo, una pérdida de sus clientes o ingresos). Otros clientes estarán muy satisfechos con su red y tampoco requiere el arquitecto y diseñador devolver y reparar la red proporcionando materiales adecuados para mantener su rendimiento requerido nivel o prematuramente la reemplazará. Ninguno de estos casos se refleja positivamente en el equipo de aplicación o arquitecto/diseñador de red y puede llevar a dedo que señala puede ser más doloroso que cualquier prueba de aceptación. Las características clave de un diseño y arquitectura de red que afectan los costos postimplementation incluyen: • Confiabilidad de la red y el sistema • Mantenimiento de red y sistema de • Capacitación de los operadores a permanecer dentro de las limitaciones operacionales • Calidad del personal requerido para llevar a cabo acciones de mantenimiento Conclusión

Algunos ejemplos de las decisiones de diseño de la arquitectura de red clave que afectan estas características: • Diversidad de componentes del camino crítico en arquitectura/diseño de redes • Calidad de los componentes de la red seleccionada para la instalación • Ubicación y accesibilidad de los componentes que requieren mantenimiento frecuente • Implementación de equipo de prueba incorporado y técnicas de monitoreo

Soporte debe ser considerado durante todo el ciclo de vida de la red. Una evaluación precisa de los requisitos para el servicio continuo a nivel de ejecución completo debe incluirse en el proceso de análisis de requisitos, junto con una declaración de requisitos específicos, mensurables. Durante los procesos de diseño y arquitectura, compensaciones deben tener en cuenta el impacto de la capacidad de soporte, y debe formularse el concepto de operaciones. Por último, durante la ejecución, deben realizarse dos tareas principales para asegurar la compatibilidad: 1. Conformidad con la arquitectura de red y el diseño debe ser validada y no conformidad corregido o documentado (al menos) para asegurar que el rendimiento es adecuado y que se puede realizar mantenimiento. 2. Operaciones y personal de mantenimiento debe comprender y estar capacitado en las tecnologías que se está implementando, incluyendo cómo funciona la red y el sistema correctamente, Cuándo realizar el mantenimiento y cómo a la mayoría rápidamente restaurar el servicio en caso de fallo. Una discusión detallada de cómo soporte encaja en los procesos de diseño y arquitectura general se proporciona en el capítulo 2.

1.11 Conclusión En este capítulo has aprendido las definiciones de análisis de redes, arquitectura y diseño; la importancia del análisis de red en la comprensión del sistema y proporciona una arquitectura defendible y diseño; y el modelo para el análisis de redes, arquitectura y procesos de diseño. También han aprendido que las redes no son entidades independientes sino una parte del sistema y que la entrega de servicios de red es una meta del sistema. Servicios de red consisten en funcionamiento y la función y se ofrecen a los usuarios, aplicaciones y dispositivos que puede lograr su trabajo en el sistema. Para el arquitecto y diseñar una red de servicios de apoyo, necesita saber qué son, cómo funcionan juntos y cómo caracterizarlos. Una vez hecho esto, usted tendrá una amplia visión de lo que la red va a necesitar de la ayuda, que usted puede tomar para los siguientes niveles de detalle como proceder con el análisis de la red. Por describir el sistema como un conjunto de componentes (por ejemplo, usuario, aplicación, dispositivo, red), puede aplicar interfaces entre estos componentes para ayudar a comprender las relaciones, entradas y salidas entre cada uno de los componentes.

También han aprendido sobre los diferentes tipos de servicios, del mejor-esfuerzo, impredecible y poco fiable al servicio algo previsible, predecible y limitada, servicios garantizados con rendición de cuentas. Para ir a un nivel más profundo en la discusión acerca de los servicios, se consideraron la capacidad de características de desempeño de servicio, demora y RMA (confiabilidad, mantenibilidad y disponibilidad). Estas características son útiles sólo si podemos medir y comprobar sus valores en el sistema. Hablamos de estos valores, así como métricas de servicio, los umbrales y límites. Aprendimos que se pueden combinar características de rendimiento en un envolvente de desempeño. Habiendo reflexionado sobre sistemas, servicios y sus características, ahora estamos listos para cuantificar lo que queremos de nuestras redes. Para ello, primero necesitamos recoger, analizar y comprender los requisitos del sistema. Se trata de análisis de requerimientos, el siguiente paso en el proceso de análisis de red.

1.12 Ejercicios 1. Fue dibujado en ejemplo 1.3, una analogía entre la arquitectura de la red y diseño de una vivienda arquitectura y diseño. Proporcionan una analogía similar, usando una computadora arquitectura y diseño. 2. Jerarquía e interconectividad son un dilema fundamental en redes. Teniendo en cuenta la jerarquía de la red que se muestra en la figura 1.30, con los costos asignados a cada enlace, muestran cómo interconectividad mejoraría el rendimiento del tráfico que fluye entre el equipo de Joe y de arena. Los costos se muestran como números pero podrían representar la capacidad de cada enlace o los costos incurridos por cada enlace. ¿Cuál es el costo total de viajar la jerarquía entre la computadora y de la arena de Joe? En esta figura, donde añadiría un enlace del coste 15 para que el costo entre la computadora y de la arena de Joe total es menos que es cuando viaja toda la jerarquía? 3. En Figura 1.9, se agregan las conexiones entre las redes en Internet para proporcionar una ruta de mejor rendimiento para flujos de tráfico seleccione. Un ejemplo de esto es un contenido de ejercicios

red de distribución (CDN). ¿Qué es una CDN? Mostrar cómo un CDN usa interconectividad para proporcionar mejores características a sus usuarios. 4. En la definición de que servicios se pueden aplicar en una red, end-to-end está determinada por donde usted quiere un servicio para iniciar y detener. Por ejemplo, si la WAN es suministrado por un proveedor de servicios (por ejemplo, un ATM o frame relay servicio), puede que desee definir los puntos finales y las características de ese servicio. Si utiliza routers de IP a cada interfaz LAN-WAN a ese servicio, describir las siguientes: (1) en los dispositivos de red definiría los puntos finales del servicio y (2) ¿Qué características (indicadores de servicio) se utiliza para medir el servicio? 5. Requerimientos de servicio de fluyen de usuario a la aplicación al dispositivo de red, cada vez más específicas a lo largo de la manera. Si te dieron un requisito de uso end-to-end de retraso (por ejemplo, 100 ms) entre un servidor de aplicaciones en una red y los usuarios de otra red, por ejemplo, ¿cómo podría que traduce en retraso en la red y dispositivos? ¿Qué tipos de métricas de servicio podría utilizar para medirla? 6. 1.5 por ejemplo, las características de retardo de los segmentos (incluyendo el procesamiento en los interruptores) son los siguientes: para cada segmento de GigE, 100 s; para el segmento de la posición OC-48 entre routers, 1 ms para cada segmento de la FE, 200 s; y para el firewall de seguridad, 5ms. Dibujar gráficos que muestran el rendimiento de retardo de extremo a extremo (en la dirección del PC del usuario al servidor) antes y después de agrega el servidor de seguridad de seguridad.

7. Cual de las siguientes aplicaciones requieren esfuerzo impredecible y poco confiable, garantizado (predecible y confiable, con la rendición de cuentas), o servicio predecible. Dar razones para sus decisiones. • Llamadas de voz de alta calidad (teléfono empresa-grado) • Voz sobre IP (VoIP) llamadas • Transferencias de archivos vía FTP • Descargas de archivos de audio • Un servicio de vídeo a la carta comercial • Acceso del usuario a los servidores de una empresa

8. Mostrar cómo umbrales y límites de funcionamiento podrían ser utilizados en los escenarios siguientes. • Una aplicación tiene un requisito de servicio para retardo de ida y vuelta a menos de 100 ms. Si el retraso es

superior a 100 ms, notificar al administrador de red. • Un usuario requiere capacidad de hasta 512 Kb/s pero no podrá exceder de 1,5 Mb/s. Desea realizar un

seguimiento de cuánto tiempo capacidad del usuario está entre 512 Kb/s y 1.5 Mb/s.

CAPÍTULO CONTENIDO 2.1 Objectives 2.1.1 Preparación 2.2 Background 2.2.1 Requisitos y características 2.2.2 La necesidad de análisis de requerimientos 2.3 Necesidades de los usuarios 2.4 Requisitos de la aplicación 2.4.1 Tipos de aplicación 2.4.2 Grupos de aplicaciones 2.4.3 Lugares de aplicación 2.5 Requisitos del dispositivo 2.5.1 Tipos de dispositivos 2.5.2 Características de rendimiento 2.5.3 Ubicaciones del dispositivo 2.6 Requisitos de la red 2.6.1 Las redes y migración 2.6.2 Administración de redes y seguridad

2.7 Otros requisitos 2.7.1 Requisitos de rendimiento suplementario 2.7.2 Requisitos financieros 2.7.3 Requerimientos de las empresas 2.8 Los requisitos de especificación y mapa 2.9 Conclusiones

2.10 Ejercicios

56

2 Análisis de requerimientos: Conceptos

En este capítulo usted aprenderá a desarrollar la descripción de los servicios de redes, identificar y derivar requerimientos de red del sistema. Usted aprenderá que requisitos de la red se juntan a los servicios y desarrollarán una especificación de requisitos para definir requerimientos y determinar sus dependencias. Aprenderá a aplicar los conceptos discutidos en el último capítulo a una variedad de requisitos de usuario, aplicación y dispositivo y desarrollar una especificación de requisitos y un mapa de aplicaciones.

2.1 Objectives En este capítulo ampliamos el concepto de requisitos para una red. Nos afine los sistemas general de ingeniería de proceso, introducido en el último capítulo, el problema de las redes. Hablamos de diferentes tipos de necesidades, desde el usuario, aplicación, dispositivos y componentes de red. Y aprendes sobre agrupar requisitos y mapeo de las ubicaciones de aplicaciones y dispositivos. La combinación de todos los requisitos y lugares se expresa en dos documentos: una especificación de requisitos y un mapa de necesidades.

2.1.1 Preparación Hay poca información sobre los requisitos de proceso de análisis tal como se aplica a las redes. Sin embargo, hay algunos excelentes materiales preparatorios de una más general ingeniería naturaleza que proporcionará una visión general de los requisitos de proceso de análisis de sistemas. 57

2.2 Background Como ya habréis notado, la parte de análisis de red de este libro, que consta de requisitos y análisis de flujo y el riesgo — introduce muchos nuevos conceptos y directrices y amplía varios conceptos existentes. Por lo tanto, análisis de requerimientos y análisis de flujo se dividen en tres capítulos, que abarcan conceptos y procedimientos, respectivamente, para que este material más legible y útil. Los capítulos en conceptos proporcionan material de fondo para cada tema, explicar y definir conceptos pertinentes. Los capítulos sobre los procedimientos de amplían estos conceptos para construir un proceso para aplicar a sus arquitecturas y diseños. Comenzamos el proceso de análisis de red con el análisis de requerimientos, que es recogida y derivados requisitos para entender comportamientos del sistema y red. Consiste en identificar, reunir, derivados y entender los requisitos del sistema y sus características; desarrollo de los umbrales y límites para el funcionamiento distinguir entre los servicios de bajo y alto rendimiento; y determinar donde se apliquen mejor-esfuerzo, previsibles y garantizados servicios en la red.

2.2.1 Requisitos y características Los requisitos son descripciones de las funciones de red y rendimiento necesario para la red apoyar con éxito sus usuarios, aplicaciones y dispositivos (y así el éxito del proyecto de red). Usando esta definición, se deben cumplir todos los requerimientos de la red para que sea exitoso. Sin embargo, como veremos, puede ser un montón de requisitos, de una variedad de fuentes, con diferentes grados de consecución. Si tenemos en cuenta todos los requisitos de todas las fuentes que sean necesarias para el éxito de la red, entonces probablemente estamos creando expectativas que no pueden cumplirse. Por lo tanto, como parte del proceso de análisis de requisitos, debemos categorizar y priorizar necesidades, determinar los que son realmente los requisitos de la red y los que pueden ser deseables pero no son realmente requisitos. Requisitos que se determinaron que es necesario para el éxito del proyecto de red se denominan fundamentales o requisitos fundamentales. Puesto que estos requisitos son necesarios para el éxito del proyecto, debe haber alguna forma para determinar el éxito. Así, asociados con cada requisito central/fundamental es de una o más métricas. Indicadores son mediciones o manifestaciones para cada requisito.

Fondo

Ejemplo de 2.1. Ejemplos de requisitos fundamentales y sus métricas asociadas son: • rendimiento: la red deberá ser capaz de proporcionar un rendimiento de extremo a extremo mínimo de 100 Mb/s entre dispositivos finales. Métrico: Medida entre seleccionar fin dispositivos (el juego de que TBD), uso de aplicaciones de (lista de aplicaciones), bajo condiciones de prueba (lista de condiciones). • Seguridad: la red deberá ser capaz de filtrar paquetes basados en una lista de Control de acceso (ACL). Métrica: Demostración de filtrado no deseados paquetes, basados en la LCA provista, inyecta en la red.

Funciones de red y el rendimiento deseado, pero no es necesario para el éxito del proyecto de red se llaman funciones. Habrá requisitos que, como parte del proceso de análisis, se determinaron que características de la red. Además, serán requisitos que pueden considerarse en una versión posterior de la red, aquellas que serán rechazadas durante el proceso de análisis y que son más informativos que los necesarios. Como se muestra en la figura 2.1, los requisitos se dividen en núcleo o requisitos fundamentales (aquellos que se consideren necesarias para esa red), características que son deseables para esa red, los que se considere en una versión o una actualización de la red, más adelante y requisitos que se han rechazado (por ejemplo, no es realmente necesario, deseable, realista y aplicable). Cada red debe tener, como mínimo, un conjunto de requisitos básicos; probablemente también tiene un conjunto de

Se reunieron los requisitos Análisis de la y derivado de los usuarios, Gestión de requerimientos, personal

Figura 2.1 requisitos se dividen en núcleo/fundamentales requisitos, características y futuro, Requisitos informativos y rechazados

requisitos informativos y puede tener conjuntos de características, necesidades futuras y requisitos rechazados. Requisitos durante el proceso de análisis de requisitos, a través de discusiones con los usuarios, gerencia y personal, han son clasificados y aprobados (firmado) por la administración. En la práctica, un primer intento de clasificación es realizado por el grupo de análisis, presentado a la gerencia para determinar si esta clasificación está en el camino correcto y luego desarrollado con la participación de los usuarios, gerencia y personal.

Un método para clasificar las necesidades se basa en la práctica actual de la Internet Engineering Task Force (IETF). RFC 2119 identifica palabras clave y frases que pueden utilizarse para describir la importancia relativa de un requisito. Estas palabras clave y frases son debe / / exigirá, no debe y no debe, debe y recomienda, no/no recomienda, y puede opcional :

• Debe / / exigirá. Estas palabras clave indicar un requisito absoluto y sería incluidas como base o

requisitos fundamentales para la red. • No / no. También son requisitos absolutos que indica una restricción o prohibición de una función o tarea. Estos también serían incluidos como base o requisitos fundamentales para la red. • recomienda/La recomienda. Estas palabras clave indican que un requisito puede ser válido, pero que su aplicación no es absolutamente necesaria para el éxito de la red. Tales requisitos catalogarse como características o requerimientos futuros de la red. • No la recomienda. Como con si/recomendadas, estas frases indican que un requisito puede ser válido (en este caso a prohibir una función o tarea), pero que su aplicación no es absolutamente necesaria para el éxito de la red. Tales requisitos también serían catalogar como características o requerimientos futuros de la red. • Puede opcional. Cuando un requisito es realmente opcional, puede catalogarse como una

característica o requisito futuro, o puede ser rechazado. Mediante el uso de estos términos, usted ayuda a asegurar que no haya confusiones con respecto a los requisitos y características. Discutimos la categorización de necesidades con mayor detalle al final del capítulo, cuando desarrollamos la especificación de requisitos. Fondo

2.2.2 La necesidad de análisis de requerimientos ¿Por qué el análisis de requerimientos? Aunque análisis de requerimientos es fundamental para el diseño y la arquitectura de red, a menudo es pasado por alto o ignorado. ¿Por qué es esto? Una razón importante que análisis de requerimientos no se dan cuenta adecuada es el grado de dificultad implicado. Reuniendo los requisitos significa hablar con los usuarios, el personal de red y gestión, interpretar los resultados. Hablar con los usuarios de N puede resultar en N + 1 diferentes conjuntos de requisitos de usuario. Dirección y el personal de la red a menudo se distanciaron de los usuarios y no tienen una idea clara de lo que quieren o necesitan los usuarios. Además, análisis de requerimientos pueden parecer que no ofrecer ninguna recompensa inmediata. Por último, análisis de requerimientos significa poner pensamiento y tiempo en preparación para la arquitectura y el diseño. No no apropiados requisitos análisis pueden resultar en un diseño y arquitectura de red que se basan en factores diferentes de lo que los usuarios, aplicaciones, o dispositivos. Por ejemplo, la red puede ser basada en una tecnología cuyo activo principal es simplemente que el diseñador se siente cómodo con él. O tal vez es una red basada en equipo de un vendedor particular, una vez más a menudo uno que el diseñador se siente cómodo con. Otro ejemplo obvio es un proyecto

que tiene una limitación de presupuesto o el plazo que obliga al diseñador a hacer y use tecnologías familiares, fácil de aplicar. Problemas con tales opciones son que no son objetivo y que conoce las tecnologías o proveedores pueden no ser las decisiones correctas para esa red particular. Requisitos análisis ayuda al diseñador a mejor entienden el comportamiento probable de la red se construye. Esto da como resultado varios beneficios: • Opciones más objetivas, conocimiento de tecnologías de red y servicios • La capacidad para aplicar a tecnología y topología de los candidatos a las redes • Redes y elementos de tamaño apropiado para los usuarios y las aplicaciones • Una mejor comprensión de dónde y cómo solicitar servicios en la red

Además, ventajas y desventajas de la arquitectura y el diseño deban realizar con la imagen total en mente. A veces esto no se hace evidente hasta que todos los usuarios, gerencia y personal ha sido consultado y todos los requisitos identificaron. Muchos rediseño resultado de esfuerzos de un conjunto inicialmente incompleto de los requisitos. Cuando proceda por el resto de este libro, verá que el proceso de análisis de requisitos constituye la base sobre la cual se construyen los procesos de diseño y arquitectura de red. En el proceso de análisis de requerimientos utilizamos requisitos para distinguir entre aplicaciones de bajo y alto rendimiento para nuestras redes; identificar servicios específicos; se reúnen los requisitos de funcionamiento para uso en análisis de flujo; y reunir otros requisitos para ser utilizado en el análisis, arquitectura y procesos de diseño. Aprendemos que baja y alta son en relación a la red en que estamos trabajando, y desarrollar y aplicar los umbrales de rendimiento y límites que nos ayude a distinguir entre ellos. Como se mencionó anteriormente, los resultados de análisis de requisitos en una especificación de requisitos y un mapa de necesidades. Una especificación de requisitos es un documento que enumera y da prioridad a los requerimientos se reunieron para su arquitectura y diseño. Requisitos mapa muestra las dependencias de ubicación entre aplicaciones y dispositivos, que se utilizará para el análisis de flujo. A lo largo de esta sección (y los otros en este libro) se presentan directrices sobre cómo se puede aplicar cada proceso. Estas directrices son de experiencia práctica y deben utilizarse como punto de partida para usted desarrollar su propio conjunto de directrices. Como proceder, te animamos a pensar en cómo podría implementarse cada pauta, y cómo desea añadir a o modificarlo.

2.3 Necesidades de los usuarios En el modelo de los componentes del sistema en nuestro sistema genérico, el componente de usuario está en la capa más alta. El término usuario representa principalmente los usuarios del sistema, pero puede ampliarse para incluir a todos los involucrados en el sistema, como los administradores de red y sistema de gestión. Comprenden el conjunto de requisitos se reunieron o

derivados de la entrada del usuario y representan lo que se necesita por los usuarios para llevar a cabo con éxito sus tareas en el sistema. Por lo general, cuando reuniendo los requisitos, todos los involucrados en esa red se consideran un usuario potencial. Figura 2.2 muestra algunos ejemplo de necesidades de los usuarios. Comenzamos describiendo los requisitos en esta capa, que conducirá al desarrollo de requisitos más específicos ya que trabajamos a través de cada uno de los componentes. Desde la perspectiva del usuario podemos preguntar, "¿Qué necesita para hacer el trabajo?" Esto resulta generalmente en un conjunto de requisitos cualitativos, no cuantitativos. Parte de nuestro trabajo en reunión y que se derivan necesidades de los usuarios es hacer cuantitativa siempre que sea posible. Necesidades de los usuarios

Figura 2.2 tipos de requisitos de usuario

En general, el sistema debe adaptarse a sus entornos y los usuarios, proporcionar transferencia y acceso a la información rápida y confiable y ofrecer servicio de calidad al usuario. Esto indica los requisitos generales siguientes: • Oportunidad • Interactividad • Fiabilidad • Calidad de presentación • Capacidad de adaptación • Seguridad • Accesibilidad • Funcionalidad • Capacidad de soporte • Crecimiento futuro

Necesidades de los usuarios son menos técnicas y son también el más subjetivo. Como se muestra en la figura 2.3, requisitos ser más técnicos al pasar de usuarios a la red. Todos estos requisitos se desarrollan con más detalle como se procede a través de la aplicación, dispositivos y componentes de red.

Nuestra intención es utilizar estos requisitos básicos como un inicio hacia el desarrollo de más objetivo y requerimientos técnicos en los otros componentes. Estos requisitos de ejemplo se presentan como una guía para su uso en el desarrollo de los requisitos de la red y pueden cambiar, dependiendo del entorno del usuario. Más alto nivel técnico por lo menos Nivel más bajo, más técnica

Figura 2.3 requisitos ser más técnicos como se mueven más cerca dispositivos de red

Puntualidad es un requisito que el usuario podrá acceder, transferir, o modificar la información dentro de un marco de tiempo tolerable. Qué marco de tiempo un "tolerable" es, por supuesto, depende de la percepción del usuario de retraso en el sistema. Es esta percepción que queremos cuantificar. Por ejemplo, un usuario puede descargar archivos desde un servidor y completar a cada transferencia en 10 minutos. O el usuario puede necesitar recibir cuadros de vídeo cada 30ms. Cada uno de estos tiempos indica un retraso que la red debe proporcionar. Puntualidad, retardo de ida y vuelta o de end-to-end puede ser una medida útil. Interactividad es similar a la puntualidad, pero se centra en un tiempo de respuesta desde el sistema (como la red) que es del orden de los tiempos de respuesta de los usuarios. En el ejemplo anterior podría considerarse como el tiempo de respuesta para el sistema de los 10 minutos necesarios para descargar el archivo, y podríamos considerar también que la transferencia de archivos está interactuando con el usuario (que es), pero el grado de interactividad es muy bajo y no de mucho interés a partir de una arquitectura o diseño. Lo interesante es cuando los tiempos de respuesta del sistema y la red están cerca de los tiempos de respuesta de los usuarios, para luego cambios en la arquitectura de red y el diseño para optimizar tiempos de respuesta pueden tener un impacto directo sobre la percepción de los usuarios de la interactividad. Por lo tanto, la interactividad es una medida de los tiempos de respuesta del sistema y la red cuando están obligados a interactuar activamente con los usuarios. Demora, aquí el retardo de ida y vuelta, es una medida de la interactividad. Utilice estas descripciones de puntualidad y la interactividad, entonces, puntualidad es más probabilidad de estar asociada con Necesidades de los usuarios

a granel transferencia de archivo o imagen, mientras que la interactividad es probable ser asociado a dispositivo remoto acceso (por ejemplo, telnet), uso de Web o visualización. Confiabilidad, es decir, la disponibilidad desde la perspectiva del usuario, es un requisito para servicio siempre disponible. No sólo el usuario debe poder tener acceso a recursos del sistema un porcentaje muy alto del tiempo, pero debe ser coherente, el nivel de servicio al usuario (en cuanto a la entrega de información o uso de aplicaciones). Así, confiabilidad está estrechamente relacionado con el rendimiento característico de fiabilidad (discutido en el capítulo 1 como parte de RMA) pero demora y capacidad también son importantes. Es probable que una combinación de todas las características de rendimiento se utilizaría para describir confiabilidad.

Calidad de la presentación se refiere a la calidad de la presentación al usuario. Esto puede ser la percepción del usuario de pantallas de audio, video o datos. Como ejemplos, considere las actuales capacidades de Internet de telefonía, videoconferencia y videos feeds (directo o diferidos). Si bien es posible hacer todo esto en Internet, hay otros mecanismos que actualmente proporcionan una calidad mucho mejor presentación. A menudo no es suficiente proporcionar una capacidad sobre una red, pero esa capacidad debe ser tan buena como o mejor que otros mecanismos, o los usuarios se sentirán decepcionados. Diseñadores y arquitectos de red a menudo se pierda este concepto. Medidas de calidad se incluyen todas las características de rendimiento. Adaptabilidad es la capacidad del sistema para adaptarse a los usuarios las necesidades cambiantes. Algunos ejemplos de esto pueden encontrarse en la distancia-independencia y movilidad. Como los usuarios confían más en la red, se están convirtiendo en servicios acoplados a lógica y desvinculadas de servidores físicos. Esta disociación significa que no tengan cuidado donde los servidores se encuentran, como pueden obtener los servicios que necesitan. Un resultado es independiente de la distancia de computación, donde el usuario pierde todo el conocimiento de donde se ejecutan trabajos de donde se obtienen los datos, almacenados, o migra a través de la red. Movilidad se refiere a la computación móvil o nómada, donde el usuario puede acceder a servicios y recursos desde cualquier ubicación, utilizando dispositivos portátiles y acceso inalámbrico a la red. Capacidad de adaptación a dicho usuario necesita requisitos de fuerzas en la arquitectura y el diseño. Seguridad desde la perspectiva del usuario es un requisito para garantizar la confidencialidad, integridad y autenticidad de un usuario información y recursos físicos, así como acceso a recursos de sistema y usuario. La seguridad es probablemente más cercana a la fiabilidad característica de rendimiento, pero que capacidad de impacto y retrasar así. Asequibilidad es el requisito de que las compras se ajustan dentro de un presupuesto. Aunque este requisito no es técnico, afecta a la arquitectura y el diseño. Lo que nos preocupa en este requisito es lo que los usuarios o gestión puede permitirse comprar por la red, para que nuestra arquitectura y el diseño no cuestan demasiado para poner en práctica. Como un requisito de usuario, veremos cómo los costos y la financiación están vinculados a usuarios, grupos de usuarios y la gestión. También consideramos fondos como un requisito de todo el sistema, de un total perspectiva del presupuesto. Funcionalidad engloba cualquier requisito funcional que tiene el usuario para el sistema. Funciones que realiza el sistema a menudo están vinculadas a las aplicaciones que se utilizan en el sistema. Funcionalidad de comprensión es importante que conduce a requerimientos de las aplicaciones (cubiertos en la siguiente sección). Parte de la funcionalidad de comprensión es determinar qué aplicaciones los usuarios realmente quieren o aplicarán en su trabajo diario. No queremos analizar las aplicaciones que no se va a utilizar. Capacidad de soporte es un conjunto de características que describe a hasta qué punto el cliente puede mantener la red funcionando a rendimiento diseñado, a través de toda la gama de escenarios de la misión descrita por el cliente en los requisitos proceso de análisis. Esto incluye el cómo los usuarios quieren o necesitan ser apoyados por su personal de operaciones de red y cualquier interfaz que tendrá con un centro de operaciones de red (NOC). ¿Por ejemplo, la red necesitará volver a configurarse para satisfacer las necesidades del usuario diferentes o cambiantes? ¿Qué aplicaciones tendrá el personal de operaciones de red y NOC para proporcionar soporte a los usuarios e identificar y solucionar problemas en la red? Información como esta se utilizará posteriormente como entrada para la arquitectura de gestión de red.

Crecimiento futuro es determinar si los usuarios están planeando desplegar y utilizar nuevas aplicaciones y dispositivos en la red. Además de estos requisitos, queremos saber cuántos usuarios se espera que en la red y sus localizaciones. Si es posible, hay que estimar el crecimiento de los usuarios en los primeros uno a tres años después de que la red se convierte en operacional, o en el ciclo de vida esperado de la red.

2.4 Requisitos de la aplicación El componente de aplicación interfaces con el usuario y el dispositivo de los componentes y es una parte esencial del análisis de requisitos. Requisitos de aplicación son requisitos que se determinan a partir de la información, experiencia o prueba y representan lo que se necesita de aplicaciones para operar con éxito en el sistema. Figura 2.4 muestra ejemplo requisitos de aplicación. Requisitos de aplicación son más técnicos que necesidades de los usuarios pero todavía pueden ser subjetivos.

Figura 2.4 tipos de requerimientos de aplicación

2.4.1 Tipos de aplicación En la descripción del sistema (usuario, aplicación, dispositivo, red), el componente de aplicación es fundamental. Este componente suele ser donde se determinan muchos requisitos de la red, como aplicaciones par usuarios y dispositivos a la red. Aplicaciones suelen ser end-to-end, entre múltiples dispositivos; por lo tanto, sus requerimientos abarcan la red subyacente. En los primeros días de la creación de redes, aplicaciones necesaria básica conectividad y transferencia de datos a través de la red. Mientras que aplicaciones todavía tienen estos requisitos, a menudo también están obligados a tener alto rendimiento o comportamiento predecible o garantizado, para soportar los requerimientos de usuario para la puntualidad, interactividad, fiabilidad, calidad, adaptabilidad y seguridad. Por lo tanto, necesidades de los usuarios influyen en requisitos de la aplicación. Podemos utilizar estos requisitos de servicio y rendimiento para distinguir entre aplicaciones que necesitan servicio predecible o garantizada y aquellos que pueden utilizar el servicio de mejor esfuerzo. Basado en requisitos de servicio y rendimiento, tipo de aplicaciones como misión crítica, velocidad crítica o real-time/interactivo, donde • Aplicaciones de misión crítica tienen predecible, garantizado, o requisitos de RMA de alto

rendimiento • Tasa crítica aplicaciones tienen requerimientos de capacidad predecible, garantizado, o alto

rendimiento

• Aplicaciones en tiempo real e interactivo han predecible, garantizado, o requisitos de retardo de

alto rendimiento Estos tipos de aplicación son descritos por sus requisitos y métricas del servicio. RMA Primero veamos RMA, de confiabilidad, mantenibilidad y disponibilidad. Confiabilidad es una medida estadística de la frecuencia de falla de la red y sus componentes y representa las paradas no programadas del servicio. Mantenibilidad es una medida estadística del tiempo a restaurar el sistema al estado de funcionamiento, una vez que ha experimentado una falla. La disponibilidad es una medida de la relación entre la frecuencia de fallos críticos y el momento de restaurar el servicio. ¿Estas medidas se refieren a las aplicaciones que usan la red? Requisitos de RMA pueden ser subjetivos. Muchos usuarios sostienen que sus aplicaciones requieren un alto grado de confiabilidad, mantenibilidad y disponibilidad de la red, pero hay algunas aplicaciones que deben mantener altos grados de RMA para poder funcionar. Una pérdida de cualquier parte de la RMA en dichas aplicaciones puede ser graves o catastróficas, tales como: • Pérdida de ingresos o de los clientes. Los ejemplos incluyen aplicaciones que manejan gran

cantidad de transacciones y el dinero, como banca de inversión, reserva de línea aérea o aplicaciones de procesamiento de tarjetas de crédito. • Información irrecuperable o situación. Telemetría procesamiento y aplicaciones de

teleconferencia son buenos ejemplos de este tipo de fiabilidad. • Pérdida de datos sensibles. Los ejemplos incluyen aplicaciones de intelligencegathering y

ID/facturación de clientes. • Pérdida de la vida. Los ejemplos incluyen aplicaciones de monitoreo de transporte o salud.

En estas situaciones el sistema no está disponible para procesar las solicitudes de aplicación de usuario o el sistema no está disponible para completar las transacciones que están en curso. Para aplicaciones como estas, una red que ofrece sólo servicio de mejor esfuerzo no suele ser adecuada, debido a su comportamiento impredecible y poco confiable. Estas aplicaciones requieren predecible o garantía de confiabilidad, mantenibilidad y disponibilidad, que puede tomar la forma de un RMA predecible o limitada, o un alto grado de RMA, o ambos. Aplicaciones que requieren RMA predecible o alta se llaman aquí aplicaciones de misión crítica . Capacidad En cuanto a capacidad, existen algunas aplicaciones que requieren una predecible, delimitado, o alto grado de capacidad. Este tipo de aplicaciones, aquí denominado aplicaciones de tasa crítica, incluye voz, vídeo no tamponado y algunas aplicaciones de "tele∗servicio" (aplicaciones que proporcionan un subconjunto de voz, video y datos para ser entregados junto a grupos de personas en varios lugares, por ejemplo, teleconferencias, telemedicina y teleseminarios [así la de tele∗]). Aplicaciones de tasa crítica pueden requerir umbrales, límites o garantías sobre el mínimo, máximo y sostenidas capacidades. Tenga en cuenta la diferencia entre aplicaciones de tasa crítica y aplicaciones de mejor esfuerzo como transferencia de archivos tradicional (donde la aplicación de transferencia de archivos no está escrita para funcionar solamente cuando está disponible un servicio predecible o garantizado). En transferencia de archivos (tales como FTP funciona sobre TCP, se ha descrito

anteriormente), la aplicación recibe cualquier capacidad disponible de la red, basada en el estado de la red en ese momento así como interacciones entre TCP y las capas inferiores. Mientras que en ocasiones que puede haber un alto grado de capacidad, es inconsistente, y no hay ningún control sobre los recursos en la red para predecir o garantizar una capacidad específica (generalmente mínima) para poder funcionar correctamente. Esto a menudo también puede estar vinculado a la demora de extremo a extremo de la red, como capacidad impactará demora. Retardo de Aumentar la interactividad es la fuerza impulsora detrás de la evolución de muchas aplicaciones. Considerar la trayectoria evolutiva de acceso a la información, de telnet y FTP, Gopher (un sistema de menús que simplifica la localización de recursos en Internet) y Archie (base de datos que consiste en cientos de directorios de archivos) al mosaico (el precursor de Netscape) y Netscape, hecho aún más interactivo con el uso de JAVA y el lenguaje de marcado de realidad virtual (VRML). Como vimos en la sección anterior, interactividad se basa predominante en el retraso característico de funcionamiento. Demora es una medida de las diferencias de tiempo en la transferencia y procesamiento de la información. Hay muchas fuentes de retardo, incluyendo propagación, transmisión, cola, procesamiento y encaminamiento. Esta sección se centra en retrasos end-to-end e ida y vuelta, que abarcan todos los tipos de demora antes mencionados. Desde una perspectiva de servicio de aplicación, optimización total, retardo de extremo a extremo, o ida y vuelta es generalmente más importante que centrarse en fuentes individuales de retraso. Fuentes individuales de retraso convertido en más importantes a medida que conseguimos en los componentes de nivel inferior, así como en la optimización de la arquitectura y el diseño. Históricamente, aplicaciones usadas en Internet no tienen requisitos de retardo estricto. Confiado en el servicio de mejor esfuerzo de Internet y no solicitar ni esperar garantías de servicio. Otras aplicaciones, se encuentran principalmente en redes privadas (con protocolos y tecnologías de red de propiedad), han tenido más demora estrictos requisitos (así como capacidad y requisitos de RMA). Algunas redes privadas han sido eficaces en la prestación de demora previsible o garantizada, por exceso de ingeniería la red con gran capacidad de repuesto, o por el compromiso de interoperabilidad con otras redes. Pero ahora encontramos que aplicaciones con requerimientos de retardo están migrando a Internet, a menudo mediante VPNs, y ahora se utilizan aplicaciones previamente dedicadas a un solo usuario o dispositivo a través de Internet, obligando a una reevaluación de ofrecer servicios que mejor esfuerzo en Internet. Esto también obliga a una reevaluación de la técnicas de ingeniería de tráfico por los proveedores de servicios. El término tiempo real ha sido interpretada para significar muchas cosas diferentes. A menudo, en tiempo real significa "tan rápido como sea posible" por los que no sabe, entiende o se preocupan por las relaciones de retraso real entre fuentes de tráfico y destinos dentro de su red. Es muy difícil cuantificar en tiempo real cuando se utiliza esta forma. Hay maneras más significativas para describir en tiempo real, así como no en tiempo real, interactivo, asincrónica, ráfaga y a granel. Estos se describen a continuación. Aplicaciones en tiempo real son aquellos que tienen una relación de estricta sincronización entre origen y destino, con uno o más contadores de tiempo fijado para la recepción de información en el destino. Información recibida después de los temporizadores expiran en el destino se considera inútil y se cae. Así, esta definición de tiempo real no significa que la información tiene que ser transferida dentro de un límite de tiempo universalmente conocido, pero que el límite de retardo se entiende por origen y destino, y que el destino no espera más allá de este límite. En tiempo real podría significar retrasos end-to-end de 30ms para algunas aplicaciones y 30 segundos para los

demás. Un ejemplo de esto es la reproducción de vídeo no protegido. Si se retrasa la secuencia de vídeo más allá del temporizador de reproducción, el destino mostrará una o más porciones en blanco de marcos (que aparecen como blips en pantalla) y el último vídeo de la gota. Esto se hace para preservar la continuidad de tiempo del vídeo que se muestra en el dispositivo de reproducción. Esto es lo que significa tener una relación de estricta sincronización entre origen y destino, que el flujo de información está sujeto a mantener la continuidad del tiempo. En tiempo real es el primero de varios términos que necesitamos aclarar. Estos términos se utilizan sin cuidado, aunque, como el arquitecto/diseñador de red, tenemos que tomarlas en serio. Por lo tanto, depende de nosotros para asegurarse de que se aclaran términos ambiguos, como junto a los requisitos basados en tales términos. Este libro intenta, siempre que sea posible, para proporcionar interpretaciones estrictas de términos para ayudar a hacerlos claro. Dada esta interpretación estricta de en tiempo real, es seguro decir que no hay muchas aplicaciones en tiempo real. Pero hay algunos (y sus números están creciendo), y es importante poder identificarlos y reconocer sus requerimientos de retardo terminante, para que tengan un fuerte impacto en la arquitectura de red y el diseño. Actualmente, la mayoría de aplicaciones se consideran no en tiempo real. No en tiempo real las aplicaciones tienen varios requisitos de retardo de extremo a extremo, a veces más estrictas (en términos de la cantidad de retardo) de aplicaciones en tiempo real, pero el factor importante aquí es que el destino espera (dentro de lo ) hasta que se reciba la información. Cuánto tiempo esperará el destino es una función de los contadores de tiempo en las aplicaciones, en los dispositivos y los protocolos utilizados. No en tiempo real los usos incluyen los interactivos y asincrónicos, que representan la gran mayoría de aplicaciones. Aplicaciones en tiempo real están en un extremo de rendimiento; aplicaciones asíncronas son en el otro. Aplicaciones asíncronas son relativamente insensibles a tiempo, suponiendo que ninguna relación de tiempo entre origen y destino, o una relación de tiempo fuera de los límites de la sesión de aplicaciones. Un buen ejemplo de una solicitud asincrónica es correo electrónico. Cuando se envía correo electrónico a un destinatario, todo el conocimiento del momento (es decir, el tiempo cuando el correo se recibe en cualquier parada intermedia o en el destino final) se pierde al remitente. Sólo si hay un error en el sistema o información del destinatario, o si se solicita, se notifica al remitente. Facsímil es otra aplicación asincrónica. Cuando se envía un FAX (cuando está protegido en el dispositivo), el remitente pierde conocimiento de cuando el FAX llega a su destino. Así como es importante identificar aplicaciones en tiempo real, debido a sus requisitos de sincronización estricta, también es importante identificar aplicaciones asincrónicas, debido a su falta de requisitos de sincronización. Aplicaciones asíncronas tienen poco o ningún impacto en el diseño y la arquitectura de red y generalmente pueden ser ignoradas. Así como hay no muchas aplicaciones en tiempo real, además no hay muchas aplicaciones asincrónicas. Así, la mayoría de aplicaciones caen en el reino no en tiempo real, entre el tiempo real en un extremo y asincrónica en el otro extremo. Estas aplicaciones se llaman interactiva. Aplicaciones interactivas asumir alguna relación de tiempo entre origen y destino mientras que la sesión de aplicación está activa; sin embargo, la relación de sincronización no es tan estricta como en tiempo real. Aplicaciones interactivas son lo que muchas personas normalmente consideraría en tiempo real, bajo la connotación de tiempo real como "lo más rápido posible". Comunes aplicaciones interactivas, tales como telnet, FTP, y aplicaciones Web, toda la caída bajo este tipo.

Finalmente, aplicaciones interactivas pueden subdividirse aún más en ráfaga y a granel de tipo interactivo. La diferencia entre estos tipos es más sutil que con en tiempo real y asincrónico. Para distinguir entre interactivo a granel y descarga aplicaciones, necesitamos primero entender cuando los tiempos de procesamiento de los componentes del sistema, particularmente el componente de aplicación, abruman el retardo extremo a extremo o ida y vuelta de la red. En otras palabras, queremos distinguir entre cuando una aplicación rápida y frecuentemente interactúa con un usuario y cuando un usuario tendrá que esperar períodos sustanciales de tiempo mientras la aplicación está procesando información. Estos tipos de demora se resumen en la figura 2.5. En base a esto, explosión interactiva aplicaciones son aquellos para los que el retardo de red endto-end o ida y vuelta es el retraso predominante para esa aplicación. Este tipo de aplicación es importante identificar, ya que es sensible al retardo de red. Así, la arquitectura de red y el diseño deben adaptarse a los requisitos de retardo de estas aplicaciones. Un ejemplo de una aplicación interactiva burst es telnet. Durante una sesión de telnet, el predominante retraso experimentado por el usuario es de la red, no de cualquier procesamiento en los dispositivos locales o alejados. Existen muchas aplicaciones de este tipo, donde los usuarios interactúan con las aplicaciones y dispositivos en toda la red y esperan respuestas "tan rápidas como sea posible". Interactivo a granel aplicaciones, por el contrario, son aquellos para los que el procesamiento en el dispositivo o aplicación componente es el retraso predominante. Así, el procesamiento de la información en uno o ambos extremos puede abrumar los tiempos end-to-end o ida y vuelta en la red. Esto es importante reconocer, como el red demora requisito aplicación se convierte en menos importante, puesto que ya queda eclipsado por retrasos de la aplicación o dispositivo. Por ejemplo, cuando una aplicación tiene demoras de procesamiento de alta, digamos del orden de 100s de ms o en segundos, tendremos mayor flexibilidad en el apoyo a retardo en la red que el retardo de procesamiento

Figura 2.5 tipos de demora

del orden de microsegundos. Un ejemplo de las aplicaciones interactivas a granel es transferencia de archivos grandes (por ejemplo, FTP). Aunque FTP tiene un grado de interacción con el usuario, puede haber épocas (especialmente cuando el tamaño del archivo es grande) cuando el procesamiento de la información en el extremo receptor, así como el tiempo total que se necesita para transferir el archivo completo, es varios órdenes de magnitud mayor que el retardo de red end-to-end o ida y vuelta. ¿Por qué la ruptura elaborada de tipos de aplicación basado en retraso? Como podemos ver en la discusión anterior, hay veces cuando el requisito de una aplicación de retraso es una consideración importante en el diseño y la arquitectura de red y otras veces cuando no está. Cuando selectivamente podemos ignorar algunas aplicaciones y centrarse en otros, los problemas de arquitectura y diseño de red se convierten en más manejables. En el siguiente capítulo se discuten algunos de los parámetros de tiempo asociados con la explosión interactiva y aplicaciones a granel.

2.4.2 Grupos de aplicaciones

Hasta ahora hemos utilizado varios ejemplos de aplicaciones para transmitir los requerimientos de las aplicaciones. A menudo es útil para aplicaciones de grupo con características similares, ya que ayuda a la asignación de características de rendimiento tanto en reunir y entender los requisitos. Ha sido útil a mí formar grupos para aplicaciones y guardar añadir a ellos como me encuentro con nuevas aplicaciones. Al tratar de identificar rápidamente los requisitos de red para un nuevo cliente, yo he utilizado con éxito estos grupos para ayudar a identificar necesidades, comparando las nuevas aplicaciones a los grupos que ya he desarrollado. Este proceso es particularmente útil si usted tiene que completar el análisis de requerimientos rápidamente o si con frecuencia tiene nuevos clientes. Mediante el proceso de análisis de requisitos, se han identificado los grupos de aplicación a continuación. Existe cierta superposición entre estos grupos, y esto no es un conjunto completo de los grupos. Se pretende ilustrar cómo funciona la agrupación. Le animamos a desarrollar sus propios grupos de aplicación como aplicar el proceso de análisis de requisitos para sus redes. • Aplicaciones de telemetría/comando y Control. Aunque el título puede sonar algo militar, este

grupo realmente describe una variedad de aplicaciones donde se transmite la información de datos y comandos entre dispositivos remotos y una o más estaciones de control de comando, control, seguimiento y determinar el estado de los dispositivos remotos. Un dispositivo remoto puede ser tan mundano como un cajero automático (ATM), los sensores en el hogar o un equipo remoto, dispositivos esotérico como vehículos remotamente pilotados (RPVs), nave o aeronaves comerciales. Aplicaciones de telemetría/mando y control se pueden caracterizar como teniendo retraso en tiempo real o interactivo, así como a menudo missioncritical. • Aplicaciones de visualización. Este grupo oscila entre visualización bidimensional de objetos y

visión de realidad tridimensional y virtual, inmersión y manipulación de objetos. Visualización puede ser de un simulaciones numéricas o de datos experimentales. Los ejemplos incluyen visualizaciones de campos de flujo de fluidos alrededor de varios objetos (por ejemplo, modelado de tiempo, aeronáutica o medicina), médicos, biomédicos y simulaciones moleculares, a simulaciones de juegos comerciales y militares. Aplicaciones de visualización a menudo pueden ser caracterizados como burst tasa crítica e interactiva. • Aplicaciones distribuidas-computación. Las aplicaciones en este grupo pueden variar desde tener

los informáticos dispositivos compartiendo el mismo bus local (como en la computación paralela), co está localizado en la misma LAN (como en un clúster de computación), para ser distribuido a través de LAN, MAN y WAN límites (como en cuadrícula, la computación ). El grado de distribución o paralelismo en la informática también está determinado por el nivel de detalle de la tarea y el grado de acoplamiento entre los dispositivos de computación. Un ejemplo de distribución informática utiliza equipos de escritorio en el ambiente corporativo por la noche, cuando están generalmente inactivos, por su capacidad de computación para realizar grandes tareas normalmente hechas en un mainframe de acoplamiento. Aplicaciones de computación distribuida se pueden caracterizar como ráfaga en tiempo real o interactivo. • Desarrollo web, acceso y aplicaciones de uso. Las aplicaciones en este grupo son los

equivalentes interactivos actuales del tradicional dispositivo remoto e información acceso utilidades telnet y FTP. Uso y acceso a la web implican acceder a dispositivos remotos y descargando o subiendo información. Esto se hace con la ayuda de interfaces gráficas. Por lo general, sesiones Web son interactivas, y la cantidad de información es pequeña en relación con los otros grupos de aplicación (con la posible excepción de telemetría y comando-y-

control). Este grupo de aplicaciones se considera generalmente para ser interactivo, una mezcla de explosión interactiva e interactivo a granel. • Aplicaciones de transporte de datos a granel. Cuando la cantidad de información deseada es

relativamente grande y las sesiones son menos aplicaciones interactivas (o asincrónicas), pueden optimizar la velocidad de transferencia de datos a expensas de la interactividad. El ejemplo tradicional es el FTP; Actualmente, hay disponibles aplicaciones más eficaces como mftp arcp . Para obtener más información sobre mftp y arcp, consulte www.nas.nasa.gov. Estas aplicaciones generalmente no tienen requerimientos de alta performance. • Tele ∗ Aplicaciones de servicio. Este grupo describe las aplicaciones que proporcionan un

subconjunto de voz, video y datos para entregarse simultáneamente a grupos de personas en varios lugares. Los ejemplos incluyen teleconferencias, telemedicina y teleseminarios (así el de tele∗). Multidifusión de Internet es un ejemplo de red de apoyo para este grupo de aplicaciones. Aplicaciones de servicio tele∗pueden ser caracterizados como teniendo retraso interactiva y en tiempo real y a menudo tasa crítica y críticos. • Operaciones, administración, mantenimiento y aplicaciones de Provisioning (OAM & P). Sistema

OAM & P applications son necesarios para el adecuado funcionamiento y operación de la red. Los ejemplos incluyen el servicio de nombres de dominio (DNS), servicios de correo/SMTP, noticias servicios/NNTP, servicio de resolución de la dirección, supervisión de red y gestión, seguridad de red y sistemas de contabilidad. Estas aplicaciones se consideran críticos e interactivo. • Aplicaciones cliente – servidor. Estas son aplicaciones cuyos flujos de tráfico comportan en una

manera cliente-servidor, tales como enterprise resource planning (ERP), suministro cadena management (SCM) y el cliente relación (CRM) herramientas de gestión. Discutimos los flujos de tráfico y comportamiento de flujo de cliente – servidor en detalle en el capítulo 4. Estas aplicaciones son a menudo críticos e interactivos. Puede aplicar más grupos de aplicación a sus redes. Si usted desarrolla los requisitos para múltiples redes, usted podrá ampliar o modificar esta lista para satisfacer sus necesidades de análisis.

2.4.3 Lugares de aplicación Además de escribir y agrupar aplicaciones, a menudo es útil para determinar cuando una aplicación se aplique en tu (o su cliente) medio ambiente. Generalmente hay algunas aplicaciones que se aplican en todas partes, que todo el mundo utiliza y que residen en casi todos los dispositivos (por ejemplo, servidores, ordenadores de sobremesa y portátiles). Sin embargo, a menudo son aplicaciones que sólo se aplican a grupos de usuarios, servidores, usuarios particulares, pisos dentro de un edificio, o edificios. Siempre que sea posible, que debe identificar este tipo de aplicaciones y donde se aplican, ya que esto le ayudará en la asignación de flujos de tráfico durante el proceso de análisis de flujo.

Figura 2.6 un mapa de aplicaciones de ejemplo

Un ejemplo de un mapa de aplicaciones, o de aplicaciones se apliquen, se muestra en la figura 2.6. En esta figura de un entorno de campus hay tres conjuntos de edificios, que se muestra en gris. Se describe el lugar donde se aplica cada aplicación. Esto es una estimación de los probables lugares para aplicaciones en un entorno y es el primer paso para proporcionar información de ubicación en el análisis de requisitos. En algunos casos todas las aplicaciones aplican en todas partes. En otros casos no podemos determinar donde se aplican algunas aplicaciones. Siempre que dicha información esté disponible, sin embargo, asignar esa información ayudará en los requerimientos y análisis de flujo. Tipos de aplicación, sus prescripciones, sus localizaciones y grupos de aplicaciones forman la interfaz entre el componente de aplicación y el resto del sistema.

2.5 Requisitos del dispositivo Pasamos ahora a los requisitos de dispositivos que dará soporte a la red, especialmente los tipos de dispositivos, sus características y su información de ubicación. Como se verá, esta información se basa en los requisitos de usuario y aplicación comentados antes para empezar a proporcionar una visión global de las necesidades del sistema. La relación de los componentes del dispositivo con el resto del sistema se muestra en la figura 2.7.

Figura 2.7 tipos de requerimientos de dispositivo

2.5.1 Tipos de dispositivos Los dispositivos pueden agruparse en tres categorías: genérico de dispositivos, servidores y dispositivos especializados de computación. Dispositivos informáticos genéricos son las computadoras de escritorio y portátiles que tienen la mayoría de los usuarios. Este grupo también incluye dispositivos de mano. Los ejemplos populares incluyen varias formas de equipos basados en Windows, ordenadores portátiles y dispositivos portátiles y Mac y estaciones de trabajo basadas en LINUX y PC. Estas son las huestes que forman los puntos de acceso a la red y servicio generalmente de un solo usuario. Sus necesidades son importantes desde una perspectiva end-toend, ya que proporcionan la interfaz entre las aplicaciones y la red. Sus necesidades también son importantes en el desarrollo de una plantilla para los dispositivos de los grupos de usuarios o todos los usuarios de la red. Estos fines dispositivos también tienden a ser pasados por alto, una forma de "caja negra" conectados a redes y aplicaciones ejecutar en pero algo de lo contrario se omiten. La falta de comprensión de los dispositivos finales ha llevado a lo que se conoce como el problema de "último pie" en el rendimiento del sistema. Se trata de una modificación de la "última milla" problema, que era la dificultad de conseguir infraestructura, redes y servicios en un campus o edificio. El problema de "último pie" está recibiendo servicios y rendimiento de interfaz de red del dispositivo a través del dispositivo a sus aplicaciones y los usuarios. Esto se discute en detalle más adelante en esta sección.

Normalmente existen muchos dispositivos de computación genéricos en un sistema, y sería difícil enumerar, describir y ver cada aparato individual. Por lo tanto, desarrollar una plantilla o estándar de descripción, de uno o más dispositivos "estándar" en el medio ambiente pueden ser útiles. Tal descripción puede incluir el tipo de dispositivo, interfaz de red, configuración, rendimiento y aplicaciones residentes. Figura 2.8 se muestra un ejemplo de una plantilla. Tipo de dispositivo

Tipo NIC

Procesador

PC gama baja

10M Ethernet

Pentium I

PC alta gama

Ethernet de 10 / 100M

PC genérico

Ethernet de 10 / 100M

Pentium

Estación de trabajo

Ethernet de 10 / 100M

AMD

Ordenador portátil

56 Kb Módem

Pentium III Y IV

OS

Aplicaciones

Win95/98/2000

Palabra, PP, finanzas

WinPro Win95/98/2000/XP

AMD

Linux

Win XP

Palabra, gráficos PP, DB, Palabra, gráficos PP, DB, DB, gráfico, CAD, SC Palabra, PP, otros

PP – Powerpoint CAD-dibujo asistido por ordenador DB-base de datos SC – científico SW Figura 2.8 una plantilla de ejemplo para las descripciones de dispositivo

Los servidores son informática dispositivos que ofrecen un servicio a uno o más usuarios (es decir, clientes). Son por lo general más potentes, en términos de memoria, procesamiento, redes y periféricos, que los dispositivos de escritorio o portátil de los usuarios. Ejemplos de servidores son servidores de cómputo, servidores de almacenamiento (también conocido como sistemas de almacenamiento masivo o archivo ) y servidores de aplicaciones. Requisitos del servidor son importantes pueden afectar a un gran número de usuarios. Como tal, sus necesidades requieren una atención sobre una base por-dispositivo de dispositivos genéricos. Los servidores también tienen requisitos de desempeño "último pie", así como requerimientos específicos a su función de servidor. Funciones de un servidor pueden racionalizarse a menudo para apoyar esta función de servidor, que a su vez puede afectar el sistema. Por ejemplo, un servidor puede ser diseñado para admitir el acceso de alto rendimiento, fiable a un gran número de usuarios. El efecto acumulativo de acceso de los usuarios a este servidor en la red debe ser considerado. Los servidores tienen un impacto en los flujos de tráfico dentro del sistema; Esto se examina en los capítulos sobre análisis de flujo. Especializada dispositivos son dispositivos que proporcionan funciones específicas a sus usuarios. Un equipo paralelo apoyar un motor de búsqueda de base de datos grande se puede considerar un servidor o un dispositivo especializado, mientras que una cámara de vídeo en la red sería considerada un dispositivo especializado. Dispositivos especializados generalmente no soportan acceso directo a las aplicaciones de usuario, pero algo reunir, producir y procesar la información a los usuarios. Ejemplos de dispositivos especializados incluyen supercomputadoras,

sistemas paralelos o computación distribuida, recopilación de datos y sistemas de procesamiento, dispositivos médicos, cámaras en red o herramientas y dispositivos de mano. Dispositivos especializados tienden a ser dependientes de la ubicación. Esto es significativo, pues mientras que en la mayoría de los entornos servidores y dispositivos informáticos genéricos se están convirtiendo en lugar independiente, dispositivos especializados a menudo mantienen sus dependencias de ubicación. Que dijo, sin embargo, hay momentos cuando dispositivos especializados son independientes y servidores o dispositivos genéricos son dependientes de la ubicación. Como veremos en la recopilación de requisitos, es importante conocer y comprender el entorno que estamos analizando, en parte para entender cualquier dependencia de la ubicación de sus dispositivos. Dispositivos especializados son a menudo dependientes debido al costo. Un túnel de viento que proporciona flujo de información para fabricantes de automóviles es grande, inmóvil y caro, lo que es difícil de replicar. Si está construyendo una red para apoyar a esta instalación de túnel de viento, ubicada en Dearborn, Michigan, la red debe ser diseñada con acceso a Dearborn en mente, así como los requisitos de rendimiento y ubicación del túnel de viento. Asimismo, si una red se construyen para proporcionar acceso remoto a dispositivos médicos (por ejemplo, escáneres CT) para los médicos, la ubicación de estos dispositivos sería requisitos de acceso para el sistema. Esto se ilustra en la figura 2.9. Mientras que los escáneres CT y túneles de viento son muy especializados (y en el caso de túneles de viento, algo bastante raros) dispositivos, este concepto pueden ser ampliados a los dispositivos más comunes, tales como cajeros automáticos, sensores de tráfico, incluso semáforos. También

Figura 2.9 especializada dispositivos

considerar información específica de ubicación, de bibliotecas, universidades, centros de gobierno o centros médicos. Mucha de esta información está también ligada a su ubicación.

2.5.2 Características de rendimiento El problema de "último pie" introducido anterior se centra en el desempeño de los diversos componentes del dispositivo: hardware, firmware y software que proporcionan el pegamento entre los usuarios y aplicaciones y el resto del sistema. Para muchos entornos, puede ser difícil de determinar o medir las características de rendimiento de sus dispositivos. Los componentes de un

dispositivo son propiedad de, e información de rendimiento sobre ellos puede ser incompletos o de carácter. Software y firmware del dispositivo, como el sistema operativo (SO), controladores de dispositivos, interfaz de programación de aplicaciones (API), de conducción son complejos. Por lo tanto, siempre que sea posible, determinar esta información para un dispositivo "estándar" y la creación de una plantilla es una solución práctica. Tomarse el tiempo para investigar o probar uno o varios dispositivos y la aplicación de esta información en una plantilla, pueden ahorrar mucho tiempo y todavía ser útil como una aproximación de primer orden de rendimiento. Tenga en cuenta que los problemas con frecuencia son malinterpretados como problemas de red. Por lo tanto, haciendo caso omiso de los requisitos de dispositivo puede comprometer la red arquitectura y diseño. Como veremos en el proceso de diseño, identificación de problemas con los dispositivos que serán apoyados por la red puede facilitar el proceso de diseño, con más resultados deterministas. Un diagrama simple y general de un dispositivo se presenta en la figura 2.10. El rendimiento de cada uno de estos componentes afecta el rendimiento general del dispositivo. Por ejemplo, buscar unidades de disco tiempos, tiempos de acceso de memoria y la efectividad del controlador, sistema operativo, o software API afecta la capacidad del dispositivo para procesar la información a y desde la red.

Figura 2.10 dispositivo componentes

Observando cada uno de estos componentes como esencial para el rendimiento general del dispositivo (y del sistema), aplicamos la perspectiva end-to-end dentro del dispositivo, el host en efecto se convierte en un microcosmos del sistema. Lo que estamos buscando en características de rendimiento incluye • Performance de almacenamiento de información, que es, flash, unidades de disco o cinta

performance • Rendimiento de procesador (CPU) • Rendimiento de la memoria (a veces) • Rendimiento de bus (bus capacidad y arbitraje eficiencia) • Rendimiento del sistema operativo (eficacia de la pila de protocolos y APIs, por ejemplo, el

número de copias de la memoria en la pila de protocolos, o el costo de la ejecución de un determinado sistema operativo en un procesador en particular) • Rendimiento de controlador de dispositivo Información acerca de cualquiera de estos componentes puede ser útil para estimar el rendimiento global de un dispositivo, o en la identificación de los factores limitantes en el rendimiento del dispositivo. Por ejemplo, ensayos de representante pueden revelar que sus interfaces de red necesitan actualizarse (por ejemplo, de 10Mb/s Ethernet a Ethernet 10 / 100Mb/s), o que las unidades de disco que deba sustituirse o que necesita una actualización de OS a realizar. Aunque puede ser mucho tiempo para comprender las implicaciones de rendimiento de

cada componente de cada tipo de dispositivo, incluso un intento simple y rápido desarrollo de rendimiento requisitos pueden ayudar a asegurar que no hay ningún rendimiento dramático obvio cuellos de botella en el dispositivo. Comprensión a nivel de componente de dispositivo puede ayudar a reconocer estos cuellos de botella en el proceso de análisis.

2.5.3 Ubicaciones del dispositivo Conocer la ubicación de dispositivos informáticos genéricos existentes o previstos, servidores y dispositivos especializados puede ser útil en la determinación de las relaciones entre los usuarios, aplicaciones y redes, así como el inicio hacia la determinación de flujo de tráfico características del sistema. Información ayuda a determinar las relaciones entre los componentes del sistema. Junto con los tipos y requisitos de funcionamiento de dispositivos, servidores y dispositivos especializados, esta información nos da idea sobre lo que deberían ser las concentraciones relativas de los usuarios y dispositivos, su colocación y el nivel de las redes necesitada.

Figura 2.11 dispositivo ubicaciones

Figura 2.11 muestra un entorno de tres campus (edificios se muestran en gris). Genérico de computación, servidores y dispositivos especializados se muestran para cada edificio. En lugar de representar cada dispositivo de escritorio de usuario, se observa un total para cada edificio. Así se muestra el número de cada servidor. Información de ubicación también ayuda a determinar las características del flujo de tráfico para el sistema. En el capítulo 4 que se discuten los modelos de flujo que describan cómo fluye el tráfico en el sistema, basado en las relaciones entre los usuarios, aplicaciones y dispositivos, se derivan parcialmente de información acerca de estos componentes. Redes para qué lugar información es particularmente importante incluyen aquellos cuyos componentes o funciones son tercerizadas; los utilizados en la consolidación de las organizaciones, componentes o funciones; y los que se utilizan en el traslado de componentes o funciones dentro de una organización.

Para ver un ejemplo de cómo se puede utilizar esta información, vamos a ver una organización que es outsourcing la reubicación de los recursos de la computadora. El agente de outsourcing puede operar, administrar, mantener y disposición (OAM & P) de los recursos en el sitio del cliente, o puede quitar los recursos del sitio del cliente y proporcionar los recursos, así como el OAM & P. En este último caso, cuando el agente de outsourcing provee recursos de computación, saber donde están los recursos para ser reubicado es importante en la determinación de los modelos de flujo y

nivel de red necesitada. El agente de outsourcing puede elegir una ubicación que está optimizada para la administración de los recursos informáticos, sin embargo, se degrada el rendimiento global del sistema. Si los recursos informáticos del cliente se accede a través de Fast o Gigabit Ethernet y luego alejados del cliente en un entorno WAN, aumentarán los costos de acceso a los recursos (por requerir conexiones WAN de alta velocidad) o el desempeño serán se degradan. En algunos casos, mover los recursos de una LAN a un entorno de WAN puede resultar en algunas aplicaciones se inutilizó. Cuando cambia la ubicación de los componentes del sistema, es importante evaluar o reevaluar los requisitos del sistema, para determinar si los requisitos de servicio (tanto rendimiento y funcional) han cambiado así. Figura 2.11 ilustra que a menudo hay ubicación dependencias entre aplicaciones y dispositivos, y que estas dependencias deben ser identificados como parte de los requisitos del dispositivo. Por ejemplo, si una aplicación de LAN que tiene un requisito para 100 ms de retardo ida y vuelta se aplica a una red WAN con un retardo de ida y vuelta de 200ms, el arquitectura/diseño de redes, aplicaciones, o las expectativas de los usuarios tendrá que ser modificado para apoyar el nueva red. La interfaz entre el componente de dispositivo y el resto del sistema consta de los tipos de dispositivos, las dependencias de su ubicación y sus características de rendimiento.

2.6 Requisitos de la red Figura 2.12 muestra la relación de los componentes del dispositivo con el resto del sistema.

Figura 2.12 tipos de requisitos de red

Para el componente de red, requisitos para un arquitectura/diseño de la red deben considerar los requisitos, servicios y características de las redes existentes que serán incorporadas o interfaz con la red nueva.

2.6.1 Migración y redes Más arquitecturas de red/diseños hoy en día necesita incorporar las redes existentes. Cuantas redes hoy están construidas totalmente desde cero. Esto incluye actualizaciones del sistema, como agregar una nueva aplicación para el sistema, migrar a una tecnología nueva o diferente o protocolo, o actualizar la infraestructura de red y la expansión o reducción de tamaño o alcance

del sistema. A veces la arquitectura de red y el diseño deben acomodar cualquier dependencias y limitaciones impuestas por la red. Los ejemplos incluyen los siguientes: Dependencias de la escala. La red existente puede afectar a cómo se escala la red planificada. Por ejemplo, ¿cómo la adición de la nueva red para la red cambiará el tamaño y el alcance del sistema? ¿El cambio será dramático, como en crecimiento de una LAN a una WAN, o será el cambio dentro de los límites de LAN/MAN/WAN de la red existente? Las dependencias del lugar. Dependiendo de cómo las nuevas redes de interfaz con o incorporan a la red existente, o cómo se hacen las modificaciones de la red, los lugares o concentraciones de otros componentes del sistema pueden cambiar. Esto se mostrará cuando desarrollamos flujos más adelante en el proceso de análisis. Las limitaciones de performance. El rendimiento global del sistema se verán afectados por nuestra arquitectura y diseño de la red prevista (o modificación de red), cómo interactúa con la red existente y sus niveles de rendimiento. Puesto que el rendimiento de la red existente afectará el rendimiento general del sistema, sus características de rendimiento deben integrarse en los requisitos de rendimiento de la red planificada. Puesto que la red ya está en marcha, es generalmente posible medir el desempeño de esta red. Así, mientras que el rendimiento de la red que se basa en una estimación mejor, el rendimiento de la red existente (y potenciales impactos en la performance) puede ser mejor entendido. Red, sistema y las dependencias de servicio de apoyo. Estos incluyen red abordando estrategias, seguridad, opciones y configuraciones de protocolos de enrutamiento y nombrar estrategias, mientras que los servicios de apoyo incluyen todo el sistema seguridad, contabilidad y control y gestión. Deben considerarse las necesidades actuales y previstas para cada uno de estos. Interoperability dependencies. Interoperability dependencies between existing and planned networks occur at boundaries between the networks, usually where different technologies or media are used. In addition, by taking an end-to-end perspective on the design, the boundaries between existing and planned networks are points where service information and performance guarantees need to be translated, or they will be lost. Requirements should include the technologies and media of the existing network and any performance and/or functional requirements from the existing network. Obsolescencia de la red. A pesar de que puede haber partes de la red existente que se integrarán a la red prevista, estas piezas, incluyendo los dispositivos de red, protocolos y software, pueden convertirse en obsoletas durante el ciclo de vida de su nueva red. Siempre que sea posible, debe tener en cuenta que partes de la red que se integrarán a la red prevista, sin embargo, están cerca del final de su utilidad, tendrá que ser la transición de la red planificada. Además, los requisitos para los usuarios, aplicaciones y dispositivos de la red existente deben considerarse como parte del sistema de construcción y su análisis de necesidades realizado junto con el análisis para las nuevas piezas del sistema.

2.6.2 Administración de redes y seguridad Ya que a lo largo de los procesos de diseño y arquitectura se discuten seguridad y administración de redes, es útil exponer brevemente sus requerimientos aquí, empezar a considerar en la arquitectura y el diseño. Es probable que nuestro análisis de la gestión de redes y seguridad en la

arquitectura y el diseño de procesos se generan nuevas necesidades o modificar algunos de los que desarrollamos aquí. En este punto en el proceso de análisis que queremos pensar en general términos sobre cómo podemos lograr gestión de red y la seguridad en la nueva red. Como veremos en los procesos de diseño y arquitectura, hay cuatro categorías de las tareas de administración de red: • Monitoreo de notificación de eventos • Planificación y monitoreo de métricas • Configuración de la red • Solución de problemas

Supervisión implica obteniendo valores para red de parámetros de gestión de dispositivos de red (routers, hubs, switches, etc.) del sistema, procesamiento de los datos, mostrando algunos o todos los datos a los operadores de red y archivo la datos. Monitoreo de notificación de eventos consiste en tomar una frecuencia instantánea de la red, para entender el estado actual de la red y para ayudar a aislar y solucionar problemas de red. Si se recogen los datos para un análisis de largo plazo del rendimiento de la red, la vigilancia es para métricas y capacidad, RMA, o ingeniería de retraso. Configuración de red y solución de problemas son las tareas más especializadas que son modificaciones de notificación de eventos, estadísticas y planificación. En el seguimiento, queremos desarrollar un conjunto de características para evento monitoreo, métricas y la planificación. Estas características pueden ser específicas para cada tipo de dispositivo de red, que se entenderá mejor más adelante en los procesos de diseño y arquitectura. También tenemos que considerar las facilidades de acceso a estas características, que incluyen protocolos de gestión de red, herramientas de monitoreo y métodos de acceso directo. Algunos problemas arquitectónicos con administración de red incluyen determinar las rutas que tendrán los datos de gestión así como de la jerarquía en los flujos de datos de gestión. Gestión de datos puede estar en la ruta de tráfico de la red de los usuarios (en banda) o puede tomar un camino diferente (fuera de banda). Para los pros y contras de la banda en versus gestión fuera de banda, vea el capítulo 7 sobre arquitectura de gestión de red. Flujos de datos de gestión pueden ser jerárquico, indicando los componentes separados de y lugares para el sistema de gestión o plana, indicando que el sistema de gestión en un solo dispositivo. Como con los otros componentes de este capítulo, las características de desempeño de gestión de redes también necesitan ser considerados. En este punto, podemos empezar a una lista de algunos potenciales requerimientos de administración de red: • Métodos de monitoreo • Métodos de instrumentación. Estos incluyen los protocolos de administración de red (SNMPv3,

CMIP, RMON), listas de parámetros (MIB), control de herramientas y métodos de acceso • Conjuntos de características para el control • En la banda versus monitorización fuera de banda

• Centralizada versus Monitoreo distribuido • Requisitos de desempeño Efecto / probabilidad

Dispositivos de usuario

Servidores

Elementos de la red

Software

Servicios

Datos

Acceso no autorizado

B/A

B/B

C/B

A/B

BYC

A/B

Divulgación no autorizada

BYC

B/B

C/C

A/B

BYC

A/B

Denegación de servicio

B/B

B/B

B/B

B/B

B/B

D/D

Robo

A/D

B/D

B/D

A/B

C/C

A/B

AIRE ACOND.

BYC

C/C

A/B

D/D

A/B

Virus

B/B

B/B

B/B

B/B

BYC

D/D

Daño físico

A/D

BYC

C/C

D/D

D/D

D/D

Corrupción

Efecto: probabilidad: A: C: destructiva A: disruptiva ciertas probabilidades de C: B: D: incapacidad sin impacto B: improbable D: imposible Figura 2.13 evaluación de riesgos de seguridad

En preparación para el desarrollo de requisitos de seguridad de nuestra red, primero debemos determinar los riesgos de seguridad. Vamos a realizar un análisis de riesgo para la red existente y nuestra red planificada, para recopilar información sobre la seguridad actual y los requisitos para nuevas características de seguridad. El análisis de riesgo a menudo se estructura como una lista de preguntas sobre la red existente, dificultades y las fuerzas de seguridad de red y debilidades. También a menudo contiene una matriz de evaluación de riesgo, que enumera los posibles problemas de seguridad, componentes del sistema que necesitan ser protegidos, y la percepción de la probabilidad y gravedad de ataques. Figura 2.13 muestra un ejemplo de una evaluación de riesgo para la seguridad de una organización específica. En este ejemplo se realizó un análisis de riesgo como parte del análisis de requisitos, y la matriz de riesgo que se muestra se completó con los valores apropiados. Requisitos de seguridad y los resultados de los análisis de riesgos se utilizan para elaborar un plan de seguridad y definir políticas de seguridad para la red.

2.7 Otros requisitos Hay otros requisitos que se aplican a través de todos los componentes del sistema, tales como financieros y requerimientos de las empresas. Hay probablemente otros tales requisitos de la red, y se incluye aquí.

2.7.1 Requisitos de rendimiento suplementario En un mundo ideal, componentes realizan según la especificación de todo el tiempo para la vida del sistema. Realidad suele ser mucho menos ordenado. Pareja que con el hecho de que los seres humanos operar y mantener los sistemas que construimos y que sus habilidades, la calidad y la moral no son siempre en su máximo significa que hay muchas cosas que pueden afectar el rendimiento de la red instalado. El mundo real se entromete en el ingeniero de red cuando él mira más allá de la red diseño e implementación de la capacidad operacional inicial (IOC), cuando los primeros segmentos sean puestos en línea en un modo de producción. Para satisfacer a los clientes y usuarios finales de esta creación, el ingeniero debe tener en cuenta que la fase cuando la aplicación de red está finalmente completa y el sistema está en manos de los operadores. Tres características del desempeño que reflejan el impacto del cliente en nuestro diseño de red son confianza, compatibilidad y conveniencia operacional. Conveniencia operativa es una medida de cómo nuestro diseño de red puede configurar, supervisar y ajustado por los operadores del cliente. Capacidad de soporte es una medida de qué tan bien el cliente puede mantener el sistema funcionando, ya diseñado, durante toda la vida del sistema. La confianza es una medida de la capacidad de la red para ofrecer los datos sin errores o pérdida en el rendimiento requerido. Identificando, documentando y validando estas limitaciones con el cliente durante la fase de análisis de requisitos, el ingeniero de red asegura que el cliente entiende las ventajas y desventajas entre el costo y rendimiento, reconoce la eliminación del tiempo de la propiedad total costos, y tiene la oportunidad de influir en estas decisiones. También reduce el factor sorpresa que podría golpear cuando el propietario ha hecho funcionar la red. Además, prepara los clientes a reconocer cuando su red ha sobrepasado la capacidad de diseño y a la Comisión una actualización o extensión de la vida de servicio o reemplazo. Los clientes que un diseño de red para conexiones de 1000 la Comisión deben ser conscientes de que, cuando su necesidad se convierte en 20.000 conexiones, necesitan una red completamente diferente; Asimismo, la necesidad de mayor confiabilidad o substancialmente más rápida restauración del servicio durante una falla también puede autorizar una nueva mirada a la arquitectura, componentes y procedimientos operativos que conforman el diseño de arquitectura.

Otros requisitos

Estos tres factores deben tenerse en cuenta en la contratación de servicios externos, como MAN, WAN, o conexiones de ISP, hardware o servicios de mantenimiento. La tasa en que ocurren fallos y la velocidad a la que se reestablezca el servicio debe ser incluida en la especificación y debe ser factores en la selección y adjudicación de servicios de conectividad de terceros. Estos factores son con frecuencia descuentos o mal entendidos por ingenieros de redes y por los clientes ellos mismos. Invariablemente, cuando los clientes piden para sus requerimientos, estos factores son tan fundamentales en su pensamiento que no piensan hablar a menos que pedido. El ingeniero de red debe asegurarse de que apropiadas preguntas como parte del proceso de requisitos y que las respuestas se documentan para que el esfuerzo de diseño correctamente les factor en las decisiones sobre la arquitectura, selección de componentes, incorporación de

servicios de terceros (p. ej., ISP), planificación de la implementación, pruebas y la capacidad operativa inicial. Confianza, compatibilidad e idoneidad operativa se describen en detalle en el capítulo 3.

2.7.2 Requisitos financieros Un ejemplo común de un requisito de todo el sistema es a restringir los gastos para el nivel de financiación para poner en práctica sólo en la red. Este requisito sirve para limitar la financiación a los dispositivos de red y servicios, en lugar de incluir otras partes del sistema (por ejemplo, ordenadores de sobremesa y servidores). Financiación a menudo está delimitada por un conjunto límite de costo, que consta de componentes de una sola vez y recurrentes. Los costos de una sola vez se basan en la planificación real y la construcción de la red y consisten en arquitectura de red, diseño, adquisición, implementación, integración, pruebas y todos los componentes de hardware y software, así como la instalación inicial o establecimiento de los servicios de los proveedores de servicios. Los costos recurrentes son para las tareas y elementos que deben ocurrir o ser reemplazado/actualizado en forma periódica. Esto incluye red OAM & P, los costos de los proveedores de servicios y las disposiciones para las modificaciones a la red. Plazos para costos recurrentes varían, impulsada por el cliente o usuario final, administración y gestión financieros ciclos y ciclos de vida de la tecnología. El nivel de financiación suele ser un obstáculo para la arquitectura y el diseño; por lo tanto, es importante saber lo que este nivel es tan temprano en el proceso de análisis como sea posible, con el fin de evitar la creación de una arquitectura y diseño que no son económicamente factibles. En conocer las limitaciones de financiamientos y los requerimientos de la red, deberíamos podemos determinar cuándo superará un arquitectura/diseño que satisfagan sus necesidades de financiamiento disponible. En la determinación de esto temprano en el proceso, podemos desarrollar argumentos para cambiar el nivel de financiación, los requisitos de la red, o ambos. Los requisitos financieros se reunieron durante el proceso de análisis se combinarán con los requisitos de accesibilidad de los usuarios, para formar una imagen económica completa de la red. Más adelante en este libro miramos limitaciones financieras a la arquitectura y el diseño y ver cómo funcionan estos procesos para optimizar la arquitectura y el diseño con el fin de minimizar los costos. Vamos a ver es a menudo beneficioso proveer de clientes varias prototipo arquitecturas y diseños, con diferencias funcionales y financieros bien definidos, para que puedan tomar decisiones claras acerca de cómo quieren gastar su dinero.

2.7.3 Requerimientos de las empresas Puede haber ocasiones cuando tienes que tener en cuenta requisitos de la red que son comúnmente considerados como requisitos de la empresa, tales como teléfono, FAX, voz y video. La integración de estos tipos de requisitos sobre la misma infraestructura de transmisión como de datos se está volviendo común, y tales requisitos de la empresa deben considerarse como parte de las necesidades globales de la red.

2.8 Los requisitos de especificación y mapa Como se señaló anteriormente en este capítulo, la especificación de requisitos es un documento que enumera y da prioridad a los requerimientos se reunieron para su arquitectura y diseño, y el mapa de necesidades muestra las dependencias de ubicación entre aplicaciones y dispositivos. Ahora discutimos con mayor detalle estos dos documentos. En pasar por el proceso de análisis de requisitos será encuentro, derivando y determinar los requisitos de una variedad de fuentes, incluyendo usuarios, gestión, administración y personal, así como de documentos sobre la red existente, su aplicaciones y dispositivos. Algunos requisitos se tomarán literalmente; otras tendrán que derivarse de la información disponible, y todavía otros tendrá que ser estimado. Los requisitos de especificación y mapa

Especificación de requisitos ID o nombre

Fecha

Tipo

Descripción

Se reunieron / derivados

Lugares

Estado

Prioridad

Figura 2.14 plantilla para la especificación de requisitos

Cuando se ha desarrollado una lista de requisitos, debe determinar qué requisitos son fundamentales o requisitos fundamentales; que pueden considerarse características deseables para la red; que puede implementarse en una futura versión o una actualización de la red; que deben ser rechazados; y que realmente proporcionan información sobre el sistema pero no las necesidades reales. Usted también necesitará priorizar necesidades para ayudar a determinar dónde se gastan los fondos, el orden en que las funciones y características se aplican, y donde se aplican en la red. Una especificación de requisitos de todos estos requisitos y especifica donde se recolectaban de o cómo obtuvieron; razones por qué requisitos eran considerados requisitos fundamentales, características, necesidades futuras, rechazados los requisitos o requerimientos informativos; y sus niveles de prioridad. Figura 2.14 muestra una plantilla para obtener esta información en una base por requisito. Los campos de esta plantilla están la siguiente: ID o nombre. Esto puede ser un número que identifica el requisito en la orden se reunió o derivado, o el nombre del requisito. Fecha. Esto indica la fecha en que se desarrolló este requisito. Tipo. Esto representa el componente de la que proviene este requisito (usuario, aplicación, dispositivo, red, otros). Descripción. Este es un listado de los detalles, en su caso, para este requisito. Como parte de esta descripción, puede indicar si el requisito es funcional o rendimiento en la naturaleza.

Se reunieron/derivados. Si el requisito se recogieron, las listas donde se recogió. Si se deriva la exigencia, esto muestra cómo fue derivado. De los lugares. Este señala que este requisito se aplica en el ambiente, si se conoce. Del Estado. Esto representa el estado actual de este requisito (base o fundamental, característica, requisito futuro, rechazado o informativo). Prioridad. Este es un número que representa el nivel de prioridad de este requisito dentro de su tipo de estado. Requisitos pueden gestionados y a través de procesadores de texto comunes y aplicaciones de software de hoja de cálculo. Los ejemplos mostrados aquí fueron desarrollados usando una aplicación de hoja de cálculo popular. También hay herramientas de software que están optimizados para los requisitos de seguimiento. La experiencia ha demostrado que la mayoría de las aplicaciones comunes de procesamiento de textos y hoja de cálculo son suficiente para esta tarea.

Ejemplo 2.2. Análisis de requerimientos para una empresa de LAN. Se hizo un primer intento para reunir los requisitos para la construcción de una red LAN. Los resultados fueron los siguientes: 1. 150 usuarios (60 ingenieros, 15HR y finanzas, fabricación, gestión de 10, 30 Marketing y ventas, 5 de 30 otros). 2. Cada área en el edificio debe ser compatible con conexiones Fast Ethernet a la red troncal. 3. Aplicaciones de base de datos, visualización, fabricación y nómina se consideran críticos para esta empresa. 4. Inventario de aplicación (INV1) para la fabricación de requisitos no determinados en este momento. 5. Aplicación de base de datos (DB1) requiere un mínimo de 150Kb/s, por sesión. 6. Usuarios de ingeniería tienen estaciones de trabajo con GigE NIC. 7. Aplicación de visualización (VIS1) de finanzas requiere hasta capacidad de 40 Mb/s y 100 ms de retardo ida y vuelta. 8. Aplicación de nómina (PAY1) requiere 100% uptime (tiempo en funcionamiento) entre finanzas y nómina exterior empresa. 9. Empresa debe estar segura de ataques de Internet. 10. Empresa requiere un mínimo de T1 acceso a Internet. Los requisitos de especificación y mapa

11. Red actual completamente reemplazará, por lo que hay no hay requisitos de red. 12. Otras aplicaciones generales: correo, procesamiento de textos, acceso a la Web interna y externa.

El primer intento de una especificación de requisitos se vería como la figura 2.15. Los requisitos simplemente se enumeran en orden, ya que no hay ningún Estado o prioridad niveles asignados en este momento. Hay dos excepciones a esto: requisitos 1 y 11 se muestran con un

Especificación de requisitos ID /

Se Fecha

Tipo

Descripción

Nombre

Lugares

Estado

Prioridad

Ver mapa

Información

TBD

TBD

TBD

Ver mapa

TBD

TBD

Ver mapa

TBD

TBD

TBD

TBD

TBD

Ver mapa

TBD

TBD

Ver mapa

TBD

TBD

Ver mapa

TBD

TBD

TBD

TBD

TBD

Ver mapa

TBD

TBD

N/A

Información

TBD

TBD

TBD

TBD

reunieron/derivados Distribución de usuario es: 60 14 01 de

1

ingenieros, 15 HR y finanzas,

Reunidos desde

Usuario ene

fabricación, gestión de 10, 30

la administración

Marketing y ventas, 5 de 30 otros Debe apoyar cada área del edificio Reunidos desde 2

12Jan01

Red

Todos

Conexiones rápidas de Ethernet a la la administración

Bldgs

red troncal Aplicaciones de base de datos, visualización, fabricación y nómina Reunidos desde 3

12Jan01

Aplicación

se consideran críticos para esta la administración empresa. Más información necesaria. Inventario de aplicación (INV1) para Recogidos de los

4

20Jan01

Aplicación

la fabricación de requisitos no usuarios (hombre) determinados en este momento Aplicación de base de datos (DB1)

14 01 de 5

Se reunieron de Aplicación

requiere un mínimo de 150 Kb/s, por

ene

Varios usuarios sesión Los usuarios de ingeniería tienen

02 01 de

Dispositivo

6

Recogidos de los estaciones de trabajo con NIC

Feb

de

usuarios (ENG) GigE Aplicación de visualización (VIS1) de

7

20Jan01

finanzas requiere de hasta 40 Mb/s

Derivados de la

capacidad y 100 ms de retardo ida y

aplicación

Aplicación vuelta Aplicación de nómina (PAY1)

11 01 de 8

requiere 100% uptime (mientras está

Reunidos desde

Aplicación Feb

en funcionamiento) entre finanzas y

la administración

nómina fuera empresa Compañía debe estar segura de 9

12Jan01

Ataques de Internet 02 01 de 10

Reunidos desde

Red la administración

Empresa requiere un mínimo de T1

Obtenida de la

acceso a Internet

red personal

Red Feb

Red actual completamente 02 01 de 11

Obtenida de la Red

reemplazará, por lo que hay no hay

Feb

red personal requisitos de red existente Otras aplicaciones generales:

12

20Jan01

correo, procesamiento de textos,

Obtenida de la

acceso a la web interna y

red personal

Aplicación externa. Más información necesaria.

Figura 2.15 el comienzo de una especificación de requisitos

Edificio A, 1er piso Sin usar

Equipar ment sala (InternetConexión)

Vestíbulo

Fabricación de (30 usuarios) (Aplicación de inventario) (Fast Ethernet para BB)

Zona Edificio A, 2ª planta

Recursos humanos y finanzas (15 usuarios) (Aplicación de nóminas Uptime del 100% cuando está activo) (Fast Ethernet para BB)

Gestión (10 usuarios) (Fast Ethernet para BB)

De la ingeniería

Ventas y Marketing (30 usuarios) (Fast Ethernet para BB)

De la ingeniería (60 usuarios) (Aplicación de visualización 40 Mb/s, 100 retraso de ms) (NICs GigE) (Fast Ethernet para BB)

Sin usar Figura 2.16 el principio de un mapa de necesidades

Estado de información (info). También, en la medida de lo posible, las ubicaciones de estos requisitos se colocan en el mapa de requisitos correspondiente. El mapa de necesidades se muestra en la figura 2.16.

2.9 Conclusiones El proceso de análisis de requisitos se trata de identificar, recoger y evaluar los requisitos de la red. Requisitos del sistema se pueden separar en componentes, donde la elección de componentes se basa en su entorno y lo que quiere lograr con el diseño y la arquitectura de red. En este capítulo se consideraron los componentes basados en los usuarios, aplicaciones, dispositivos y redes. Este es un punto de partida para la agrupación de requisitos. Al desarrollar su propio proceso de análisis de requerimientos, debe determinar cómo sería grupo de requisitos. Ejercicios

Requisitos constituyen la base sobre la cual desarrollar la arquitectura de red y el diseño. La experiencia demuestra que el esfuerzo más pone en el desarrollo de un buen conjunto de

requisitos y comprensión del sistema que será apoyado por esta red, el mejor su diseño y arquitectura de red. Separando requisitos del sistema en componentes, el conjunto de requisitos se vuelve más realizable. Como aplicar los procesos, principios y directrices del próximo capítulo a cada uno de estos componentes, usted comenzará a ver cómo entender cada componente ayuda a construir una imagen del sistema en general. Haber cubierto los conceptos de análisis de requisitos, estamos listos para discutir el proceso de análisis de requisitos. Mientras se trabaja a través del siguiente capítulo, tenga en cuenta el conjunto de requisitos que hemos identificado aquí para cada componente del sistema y cómo se pueden combinar en una especificación de requisitos y requisitos de mapa.

2.10 Exercises 1. ¿Por qué conviene análisis de requerimientos diseño y arquitectura de red? Da tres razones. 2. Categorizar cada uno de los siguientes requisitos como base/fundamental, característica, o informativo. a. Red debe soportar interfaces Fast Ethernet y Gigabit Ethernet para todos los dispositivos en la red. b. Red troncal debe ser actualizable en capacidad a 10Gb/s dentro de dos años de la implementación de. c. Departamento de finanzas requiere protección de firewall en el servidor. d. Red existente consiste en segmentos de 10BaseT Ethernet y FDDI. e. Personal de la red quisiera poder facturar a los usuarios de servicio de red. f. Núcleo de la red no debe generar o terminar cualquier tráfico de usuario. g. Red debe soportar tráfico de vídeo digital de cámaras de video remotos y puede además sonido de estas cámaras. 3. Categorizar cada uno de los siguientes requisitos como usuario, aplicación, dispositivo o red. a. Servidores de base de datos deben ejecutar software de marca XYZ. b. Teleconferencia requiere menos capacidad de 350Kb/s. c. Los usuarios deben ser capaces de enviar trabajos de impresión de hasta 25MB de tamaño. d. Cada red debe ser capaces de 200 usuarios del servicio. 4. Dan un ejemplo de un requisito que flujos de usuario de aplicación en el dispositivo a la red. Mostrar cómo se vuelve más técnica en cada componente. 5. ¿ Que a continuación los requisitos cliente podrían catalogarse como críticos? ¿Como crítico de velocidad? ¿Como en tiempo real? ¿Como ninguno de estos? Dar razones de cada elección. a. Procesamiento de datos de telemetría desde el lanzamiento de un transbordador espacial y proporcionar los datos para el control de la misión durante el lanzamiento. (Cliente: NASA.) b. Procesamiento de peticiones de cajeros automáticos a lo largo de una ciudad. (Cliente: Banco.) c. Procesamiento de las solicitudes de páginas Web de sus servidores. (Cliente: proveedor de Internet.) 6. Dan un ejemplo de una aplicación de misión crítica para cada uno de estos tres ambientes: comercial militar, gobierno,. ¿Por qué cada aplicación se consideraría esencial? 7. Sección 2.4.1 describe varios tipos de delay (explosión en tiempo real, interactivo, interactive a granel y asincrónica). Dar ejemplos de aplicaciones o tipos que tienen cada tipo de retraso del tráfico. 8. Retraso rendimiento es cada vez más importante en apoyo de requisitos de usuario y aplicación. Describir por qué la demora es importante para las siguientes aplicaciones: • Voz sobre IP (VoIP) • No amortiguada (reproducción en tiempo real) video o audio

• Teleconferencia

9. Con base en los siguientes lugares de aplicación, desarrollar un mapa de aplicaciones usando la plantilla (ver figura 2.17).

Figura 2.17 plantilla ejercicio 9

Ejercicios

a. Es una aplicación de computación distribuida entre todos calcular servidores. b. Es una aplicación de almacenamiento y acceso de datos entre todos los servidores de cálculo y los servidores de almacenamiento de información principal ingeniería. c. Es una aplicación de migración de datos entre la principal ingeniería, edificio de acceso externo y fuera del archivo de datos. 10. ¿ Los dispositivos que a continuación pueden ser considerados dispositivos informáticos genéricos? Servidores? ¿Dispositivos especializados? a. Cajero automático un. b. Portátiles ejecutando Linux OS. c. Cluster computing de IBM de 128pzas. d. Servidor Sun Enterprise 450 e. PC de sobremesa con Windows 2000 11. Añadir los siguientes dispositivos en el mapa de aplicaciones desarrollado en el problema 4. a. Calcular los servidores se encuentran en edificios A, B y C (un servidor), y cinco calcular servidores se encuentran en cañería ingeniería. b. Servidores de almacenamiento se encuentran en la principal Ingeniería (dos servidores), edificio de acceso externo (un servidor) y en la ubicación del archivo de datos fuera del sitio (un servidor). 12. Lista de las 10 mejores aplicaciones que esperas usar en tu (o su cliente) red, o que utilizas en la red. Lista de las características de rendimiento reales o estimadas para cada aplicación y tratar de colocarlos en grupos. También puedes asignar a los grupos de aplicación enumerados en la sección 2.4.2.

CAPÍTULO CONTENIDO 3.1 Objectives 3.1.1 Preparation 3.2 Encuentro y listado de requisitos 3.2.1 Determinar las condiciones iniciales

3.2.2 Ajuste de las expectativas del cliente 3.2.3 Trabajar con los usuarios 3.2.4 Tomar mediciones de rendimiento 3.2.5 Seguimiento y gestión de requisitos 3.2.6 Mapeo de información de ubicación 3.3 Desarrollo de métricas de servicio 3.3.1 Herramientas de medición 3.3.2 Dónde aplicar métricas de servicio 3.4 Caracterizar el comportamiento 3.4.1 Modelado y simulación 3.4.2 Comportamiento de los usuarios 3.4.3 Comportamiento de la aplicación 3.5 Desarrollo de requisitos de RMA 3.5.1 Fiabilidad 3.5.2 Capacidad de mantenimiento 3.5.3 Disponibilidad de 3.5.4 Los umbrales y límites 3.6 Desarrollo de requisitos de retardo 3.6.1 Demoras de extremo a extremo e ida y vuelta 3.6.2 Variación del retardo 3.7 Desarrollo de requisitos de capacidad 3.7.1 Estimación de índices de datos 3.8 Desarrollo de requisitos de rendimiento suplementario 3.8.1 Conveniencia operativa 3.8.2 Capacidad de soporte 3.8.3 Confianza 3.9 Límites y umbrales específicos de medio ambiente 3.9.1 Comparación de requisitos de aplicación 3.10 Requisitos para el funcionamiento previsible y garantizado 3.10.1 Requisitos de Performance predecible 3.10.2 Requisitos para rendimiento garantizado 3.11 Asignación de requisitos 3.12 Desarrollo de la especificación de requisitos 3.13 Conclusions 3.14 Exercises

98

3 Análisis de requerimientos: proceso Los principios, directrices y procedimientos para el análisis de requerimientos son parte del modelo de proceso. Este modelo, que se muestra en la figura 3.1, describe los pasos principales para recopilar, analizar y desarrollar los requisitos de la red.

3.1 Objectives En este capítulo usted aprenderá sobre recolección y manejo de usuario, aplicación, dispositivo y requisitos de la red. Esto incluye la configuración y gestión de las expectativas de sus clientes sobre la red. Usted aprenderá acerca de cómo determinar las variables a medir (métricas de servicio) y cómo hacer las mediciones. Introducimos el modelado y simulación, y cómo ellos y otras técnicas de aproximación pueden utilizarse para describir el comportamiento de usuario y aplicación. Usted aprenderá acerca de los requisitos de rendimiento en desarrollo de capacidad, retraso y RMA, con desarrollo de umbrales de rendimiento y límites. Estos son útiles en la distinción entre requisitos de alto rendimiento de bajo de la red. Usted aprenderá sobre los umbrales generales y específicas del entorno y límites y cómo determinarlas. Algunos umbrales generales se presentan para su uso. También discutimos los requerimientos de desempeño previsible y garantizada y su importancia. Junto con la recopilación y desarrollo de requisitos, usted aprenderá acerca de asignación de requerimientos a localizaciones geográficas, en preparación para el análisis de flujo de tráfico.

3.1.1 Preparation El material en este capítulo se basa en lo que fue presentado en el capítulo 2. Por lo tanto, las recomendada fuentes de información enumeradas en el capítulo 2 también se aplican aquí. 99

Figura 3.1 el proceso de análisis de requisitos

3.2 Encuentro y listado de requisitos Requerimientos de servicio son reunidos y con condiciones iniciales en la arquitectura y diseño, con la participación de los usuarios, la administración y gestión y luego refinados aplicando nuestra experiencia y conocimiento sobre el proceso de análisis. En este capítulo se dan algunas pautas para cuantificar requerimientos y desarrollo de los umbrales y límites, pero primero debemos comunicarnos con los usuarios para reunir sus necesidades. Comenzamos con una discusión de las condiciones iniciales en la red.

3.2.1 Determinar las condiciones iniciales Las condiciones iniciales son la base para el inicio del proceso de análisis. Ayudan a determinar lo que está diseñando, así como las razones de la arquitectura y el diseño. Condiciones iniciales consisten en el tipo de proyecto de red, el ámbito de la arquitectura y diseño, diseño de arquitectura inicial metas y cualquier fuerza exterior actuando sobre la red. Es necesario entender estas condiciones iniciales, ya que influirán en la arquitectura de red y el diseño y a menudo actúan como restricciones en el diseño de arquitectura. Las condiciones iniciales podrían considerarse también el estado actual de la arquitectura y el diseño de la red existente.

Antes de iniciar el proceso de recolección y análisis de requisitos, es probable que tenga alguna noción de las condiciones iniciales para la red del proyecto le

están llevando a cabo. Por ejemplo, usted probablemente sabe el tipo de proyecto de red, así como el alcance del proyecto. Algunos ejemplos de estos son los siguientes: Tipo de alcance del proyecto de red de proyecto de red • Nueva red • tamaño de la red • Modificación de una ya existente • número de sitios de la red • Análisis de problemas de red • distancia entre sitios • Outsourcing • Consolidación • Actualización Usted puede conseguir sus objetivos de diseño de arquitectura inicial de su cliente, y parte de este proceso es validar esos objetivos, posiblemente añadiendo a, restando de o modificar durante el proceso. Ejemplos de tales objetivos son: Objetivos de diseño de arquitectura inicial • Proveedor de tecnología de actualización • Mejorar el rendimiento a parte o la totalidad de la red • Apoyo a nuevos usuarios, aplicaciones o dispositivos • Resolver problemas en el sistema • Aumentar la seguridad • Apoyar una nueva capacidad en el sistema Inicialmente, usted no incluso puede conocer fuera de las fuerzas, ya sean políticas, administrativas o financieras, actuando en la red a menos que seas parte de la organización que solicita el trabajo. Por lo tanto, es probable que algunos, pero no todos, de las condiciones iniciales para el diseño/arquitectura de redes. Conocer el tipo y alcance del proyecto de red le ayuda a enfocar sus esfuerzos. Por ejemplo, sustituyendo una red antigua con un totalmente nuevo minimiza el número de restricciones al arquitectura y diseño de la red (excepto posiblemente ninguna red externa existente que tendrá la nueva red para la interfaz con), lo que le permite centrarse en objetivos de diseño arquitectónico para esta nueva red. Cuando el proyecto es una modificación o una actualización de una red existente, tiene más restricciones de la red existente. La red proporciona información sobre el comportamiento actual de la red y lo que se puede esperar de los cambios a la red. La red existente limita la arquitectura y el diseño desde la perspectiva de cómo conectar e interactuar

con parte de o toda la red existente. Así, el rendimiento y las funciones de la red existente, junto con las razones para hacer cambios a la red, son importantes condiciones iniciales. Estas condiciones también se aplican cuando usted está haciendo solamente el análisis de una red. En este caso la red puede no funcionar según lo previsto, y están intentando determinar que existen problemas en la arquitectura o diseño, o donde la aplicación varía desde el arquitectura y diseño. Si usted está construyendo una red para permitir la externalización de recursos que OAM & P, entonces las condiciones iniciales se incluyen donde ocurrirá la externalización y los métodos utilizados por el agente de outsourcing para proporcionar funciones OAM & P. Es probable que varias limitaciones en el diseño y la arquitectura de red. Mediante el examen de las condiciones iniciales en el inicio del proceso de análisis, se pone de pie una mejor oportunidad de entender, eliminación o trabajar con estas limitaciones. Restricciones comunes en un proyecto de red incluyen financiación limitaciones; trabajo con varias organizaciones o grupos dentro de una organización; Reglamento de organización y reglamentos; limitaciones de tiempo y horario; y limitaciones técnicas de los usuarios, aplicaciones, dispositivos, redes y la administración. Limitaciones de financiamientos son esenciales para el proyecto de la red. Como veremos en los procesos de arquitectura y diseño, opciones de diseño de la arquitectura están acoplados a fondos disponibles. Haciendo caso omiso de financiación en el proceso de análisis puede conducir a decisiones de arquitectura y diseño que no se implementará, si bien teniendo en cuenta esta limitación en el frente ayuda a hacer el uso más inteligente de la financiación para la red. En este sentido limitaciones financieras pueden considerarse como positivo, en que fuerza el arquitecto de la red para desarrollar soluciones creativas para adaptarse a las limitaciones de financiación. También es importante que como buen pronóstico para la futura financiación como sea posible. Restricciones organizacionales, como quien va a trabajar con cómo interactúan los grupos, pueden convertirse en problemas durante el proyecto. Sabiendo de antemano estas limitaciones le permite prepararse para cualquier problemas de organización, generalmente por buffering a sí mismo y el proyecto de problema grupos o individuos. A veces, pero no siempre, gestión puede ayudar con este tipo de restricción. A menudo hay restricciones políticas al proyecto de la red. A veces la solución técnica a un problema de red está limitada por los deseos políticos de usuarios, administración o personal. Estas limitaciones pueden ser el más difícil de todos, ya que a menudo son ilógicas. Sin embargo molestas que puedan parecer, restricciones políticas deben ser consideradas como parte del proyecto red. Dependiendo de su posición en el proyecto, podría tener opciones sobre cómo tratar con este tipo de restricción. Como consultor puede diferir a la gestión en relación con la política, o incluso rechazar el proyecto. Como empleado, sin embargo, usted es más probable que sea una parte integral de la organización, no fácilmente separada de asuntos políticos. Los componentes existentes en el sistema a menudo actuarán como restricciones. Los usuarios sufren de inercia, no querer aceptar los cambios en las formas que hacen su trabajo. Aplicaciones escritas para ser utilizado localmente en un dispositivo o de una red determinada tecnología o protocolo tendrá que ser modificado para funcionar en la nueva red. Controladores e interfaces de dispositivo tenga que ser cambiado o actualizado. Redes traen sus prestaciones y limitaciones funcionales para el proyecto. Al saber temprano en el proceso de qué partes del sistema existente se debe incorporar o apoyo en la nueva red, puede determinar qué arquitectura opciones trabajará y, apenas como importante, que no va a funcionar.

Parte de las condiciones iniciales para el proyecto de la red puede determinar su objetivo de rendimiento: rendimiento de múltiples nivel o solo nivel rendimiento (Figura 3.2). Redes de multinivel rendimiento suelen tener uno o algunos aplicaciones, grupos de usuarios o dispositivos cuyos requisitos de desempeño son significativamente mayores que otros requisitos de rendimiento para esa red. Como resultado hay un umbral entre requerimientos de bajo y alto rendimiento para este tipo de red. Por lo general, este conjunto de unidades de alto rendimiento requisitos cómo y donde el rendimiento está diseñado en la red. Por otro lado, redes de rendimiento de la solo-grada no tienen un conjunto distintivo de aplicaciones, usuarios o hosts que tienen significativamente mayores requisitos de funcionamiento para esa red; por lo tanto, no hay ningún umbral entre bajo y alto rendimiento para este tipo de red. Esto es significativo en que, sin un conjunto de requisitos de alto rendimiento cómo y donde el rendimiento está diseñado en la red, el rendimiento está diseñado para apoyar todos igualmente. Red de varios niveles de rendimiento: Donde uno o unos aplicaciones, grupos de usuarios o

Red de rendimiento solo nivel: Ningún distintivo conjunto de aplicaciones, usuarios o hosts que

dispositivos cuyos requisitos de desempeño son

tienen significativamente

significativamente mayores que otros requisitos de

mayores requisitos de funcionamiento para esa

rendimiento para esa red

red.

Alta Alta

Figura 3.2 determinación de objetivos de rendimiento: Rendimiento simple o multi-Tier

Este es uno de los conceptos fundamentales de este libro, que se discute en mayor detalle en los procesos de diseño y arquitectura. Para muchas redes puede que necesite tener en cuenta ambos tipos en su arquitectura y diseño. Determinar las condiciones iniciales de la red lleva en el proceso de análisis de requisitos. Usted debe saber algunas de las condiciones iniciales y tendrá que aprender otros. Como usted comienza a cavar para encontrar respuestas, están reuniendo información para el proceso de análisis.

3.2.2 Ajuste de las expectativas del cliente En este punto en el proceso de análisis es importante comenzar a las expectativas del cliente. Esto consiste en: • una rápida evaluación inicial del problema, y • estimación de recursos y programación

Esto no pretende ser una estimación detallada, sino más bien una evaluación rápida para detectar problemas obvios. Cómo rápido la evaluación depende, en parte, su papel en el proyecto. Si usted es un consultor o asesor, que tenga que ser muy rápida, del orden de horas o días. Si usted es el arquitecto y diseñador de la red para la red de la organización, pueden tener semanas para hacer la evaluación. En general, esta evaluación puede hacerse del orden de unos pocos días. La

intención es informar a los clientes, temprano en el proceso, cuando sus expectativas son poco realistas. Esto ayuda a realinear al cliente, si es necesario y evita backloading del proyecto. Habrá momentos cuando encuentre que los clientes definición del problema y sus expectativas, es absolutamente correcta. Generalmente, sin embargo, sus expectativas hay que ajustar algo. Y puede haber ocasiones cuando usted encuentra que sus expectativas y sus expectativas son hasta ahora aparte de que es mejor no seguir en ese proyecto. Es mejor descubrirlo temprano en el proyecto. Cuando son posibles, declaraciones de problema pueden ser muy útiles para su proyecto. Las declaraciones de problema son las descripciones de cada uno de los problemas que se aborda el proyecto de la red. Declaraciones de problema constituyen la base del proyecto red. Requisitos deben acoplarse a las declaraciones de problema durante el proceso de requisitos. De esta manera, nos aseguramos de que cada requisito está asociado a uno o más problemas, y que cada problema tiene algunos requisitos aplicadas a él.

3.2.3 Trabajo con usuarios En el trabajo con los usuarios, puede ser tu primera inclinación a pensar "Esto toma demasiado tiempo," "no son cooperativos", "no saben lo que quieren", y así sucesivamente, pero esto es una parte vital, si a veces dolorosa, del proceso. Por inicialmente pasar tiempo con los usuarios, obtendrá una mejor comprensión de los patrones de comportamiento y entorno. Para los usuarios finales, discutiendo sus planes red con ellos les ayuda a comprender lo que está tratando de lograr y construye líneas de comunicación personal que te será útil cuando son instalación, depuración y operando la red más adelante. Aunque puede ser difícil comunicarse con los usuarios (incluyendo la administración y gestión), hay algunas técnicas exitosas que se pueden utilizar: • desarrollo de una encuesta para correo electrónico, FAX o correo a los usuarios • seguimiento de la encuesta con llamadas telefónicas individuales o llamadas de conferencia • Seguimiento de llamadas con reuniones cara a cara con las personas o grupos • Sesiones de pizarra para obtener ideas de los usuarios • Pasar tiempo con los usuarios mientras trabajan para entender mejor lo que hacen y cómo lo

hacen Un intercambio de claves es la cantidad de tiempo frente a la calidad de la información recopilada. Trabajar con su gestión, administración y los usuarios paga de otra manera, que ellos vean que usted está tomando una actitud activa, de sistemas en el proyecto de la red, no sólo desarrollo de una red "en la oscuridad." En orden para el sistema satisfacer las necesidades de los usuarios, los usuarios deben ser capaces de comunicar estas necesidades las aplicaciones tienen que ser diseñados para trabajar a través de la red; y dispositivos deben ser elegidos con el sistema de la mente. Puesto que la red es fundamental para el sistema, su papel en traer el enfoque de sistemas a los usuarios es importante. En cierto sentido, son propiciar apoyo para la red, su arquitectura y diseño y su papel en el sistema. Por lo tanto, es importante no adoptar un enfoque relámpago, hablar con los usuarios para obtener sus requisitos y no seguimiento con ellos. Estableciendo relaciones con los usuarios,

administración y gestión, a través de discutir sus necesidades, asesorándolos de resultados y acciones anticipadas informándoles del progreso con el proyecto de la red, están desarrollando defensores de su red. Esto puede ser vital cuando usted necesita actualizar la red en el futuro, o si tiene que defender su arquitectura y diseño de las decisiones. Mientras que reuniendo requisitos, busque señales de advertencia, también conocidas como "banderas rojas". Por ejemplo, señales de advertencia se producen cuando hay una falta de precisión o claridad en los requisitos, tales como las siguientes: • Mal uso del "tiempo real" • Disponibilidad únicamente un porcentaje (99.99%) • "Alto rendimiento" sin verificación • Requisitos altamente variables, inconsistentes • Expectativas del cliente

Cuando encuentras esas señales de advertencia, debe intentar, cuando sea posible, para aclarar el significado de la declaración. Más adelante en este capítulo discutimos maneras de aclarar varias banderas rojas. Cuando reuniendo los requisitos e interactuar con los usuarios, es un buen momento para evaluar la opinión que tienen los usuarios de la red actual, así como el personal de operaciones y redes.

3.2.4 Tomar mediciones de rendimiento Siempre que sea posible, es útil medir los niveles de rendimiento de aplicaciones y dispositivos que se utilizarán en la red planificada. Esto se realiza mediante ensayos de aplicaciones y dispositivos en una red separada y controlada (por ejemplo, red de banco de pruebas) o mediante la medición de sus niveles de rendimiento en la red. Construcción de un pequeño Banco de pruebas de red para medir el rendimiento de la aplicación y el dispositivo puede servir múltiples propósitos. Ya que es controlada por una red de banco de pruebas, puede asegurarse que hay suficiente capacidad disponible para sus aplicaciones y dispositivos. Así, la red no limita el rendimiento de las aplicaciones y dispositivos bajo prueba. Usted será capaz de medir un rendimiento máximo, que puede derivar requisitos de rendimiento para las aplicaciones y dispositivos. Las mediciones de rendimiento máximo de aplicación y el dispositivo pueden utilizarse para determinar cuánta degradación en el rendimiento se experimenta en la red. Estas mediciones se convierten en una validación de los problemas de rendimiento en la red. Junto con las mediciones de rendimiento, puede a menudo capturar todo el tráfico de una sesión de aplicación, monitorizando promiscuo de la red. Esta información es útil para caracterizar y modelar comportamientos de aplicación y el usuario, discutidos en la sección 3.4. Herramientas que pueden ayudar a capturar tráfico incluyen Sniffer Ethereal y Etherpeak.

Figura 3.3 medición del rendimiento utilizando un banco de pruebas y en la red

Si no puede construirse una red de banco de pruebas para medir el rendimiento, pueden realizar las mediciones en la red (si está autorizado por la dirección). Mientras que usted será capaz de obtener datos de rendimiento con esta técnica, la red existente limite y rendimiento. Esta técnica todavía es muy útil para capturar tráfico para caracterizar y modelar comportamientos de aplicación y el usuario. Estas dos técnicas se muestran en la figura 3.3.

3.2.5 Seguimiento y gestión de requisitos Requisitos también necesitan ser rastreados y gestionados. Debe mantener un listado de requisitos hasta la fecha, en un lugar donde todos los involucrados en el proceso tienen acceso a ellos. La Web es una gran herramienta para el registro, seguimiento y gestión de requisitos. Hay una serie de métodos utilizados para rastrear y gestionar los requisitos; dos de estos se muestran a continuación. En primer lugar es apartado, donde un requisito se cambia dentro de su apartado original. 3.1 se muestra un requisito en esta forma.

Ejemplo 3.1. A continuación se muestra un requisito para la actualización a equipo de red. NR - 1.0-102. Todos equipos para redes (tecnología una 07/03/2007) deberán ser capaz de software (o firmware 01/04/2000) (eliminado 17/04/2007) basado en actualizaciones para soportar los cambios de funciones y características de servicio de datos de alta velocidad (cualquier 20/05/2007). Este requisito se modificó como parte del proceso de análisis. Como se puede ver, se realizaron cambios en diferentes épocas, que reflejan la evolución de los requisitos de como hablar a los usuarios, gerencia y personal. En este ejemplo uno de los requisitos (para actualizaciones de software-basado) fue cambiado en 01/04/2007 para incluir actualizaciones de firmware, que luego fue suprimido en 17/04/2007, restaurándolo a su forma original. Es importante tener en cuenta que, mientras que un requisito evoluciona, la descripción de ese requisito guarda todos los cambios visibles. En este ejemplo se puede saber lo que era el requerimiento original y cómo ha cambiado. Así, si alguien quiere hacer un cambio que se ha intentado antes, él o ella sabrá antes.

Otro método para rastrear y gestionar los requisitos es utilizar un formulario tabular. En este método el requisito se mantiene en su forma original, y los cambios que se agregan a una tabla. La figura 3.4 muestra cómo se hace, con el requisito del ejemplo 3.1.

Otras herramientas de software pueden utilizarse para este proceso, como hojas de cálculo y bases de datos. El punto clave aquí es que documentos de requisitos deben ser documentos vivos, actualizados regularmente para reflejar la naturaleza cambiante de la red y sistema. Como una lista de lo que el sistema necesita de la arquitectura de red y el diseño, estos requisitos se utilizará como base para el resto de este libro. Las condiciones iniciales, restricciones y cualquier hipótesis sobre el medio ambiente del proyecto de red deben ser incluidos en la lista de requisitos. Esto ayuda a determinar los componentes del sistema para el que necesitamos obtener más información.

ID o nombre

Fecha

Tipo

Texto original en

01Jan2007

Descripción Todo el equipo de red deberá ser capaz de actualizaciones basado en software que le permita soportar los cambios a las características del servicio de datos de alta velocidad y funciones.

07 de marzo de 2007

Cambio

"Todos los equipos de red" cambiaron a "Tecnología"

01 de abril de 2007

Cambio

"basados en software upgrades" cambiaron a "software o actualizaciones de firmware"

17 de abril de 2007

Eliminación

NR - 1.0-102

20 de mayo de 2007

Cambio

Cambio del 01 de abril de 2000 eliminado

"alta velocidad" cambió a "cualquiera"

Figura 3.4 requerimientos de seguimiento y la administración en forma de tabla

Desarrollo de métricas de servicio

Figura 3.5 un área metropolitana ejemplo mapa

3.2.6 Información de ubicación cartográfica Como parte del proceso de análisis, las ubicaciones de aplicaciones y dispositivos que asignarse para mostrar sus ubicaciones físicas relativas. En el capítulo 2 hemos introducido el concepto de mapeo de aplicaciones y dispositivos. Mientras que reuniendo los requisitos, debe tener en cuenta (cuando sea posible) la ubicación de servidores y dispositivos especializados, y donde se utilizan aplicaciones específicas. Figura 3.5 muestra un ejemplo de cómo se hace con un entorno de área metropolitana con dispositivos y aplicaciones.

3.3 Desarrollo de métricas de servicio Después de reunir los requisitos de nuestra red, el siguiente paso es analizar estos requisitos con el fin de distinguir entre distintos niveles de rendimiento en la red. Desarrollar y utilizar los umbrales de rendimiento y límites para distinguir entre bajo y alto rendimiento y también utilizar características para identificar los niveles de performance predecible y garantizadas. Los umbrales de rendimiento y límites y características de rendimiento se miden en el sistema de métricas de servicio. Métricas de servicio son bien reales cantidades mensurables en la red o se derivan de cantidades medidas. Estas métricas de servicio son importantes, como son donde "el caucho resuelve el camino", donde los requisitos de todas las capas en el sistema son destilados en cantidades medibles y configurables. Recuerde del capítulo 2 que en orden para una característica de funcionamiento ser útil, debe ser configurable, medibles y verificables dentro de la red. Esto es particularmente cierto cuando partes de la red están fuera del control del administrador de red, por ejemplo, cuando un proveedor se utiliza para proporcionar un servicio como Frame Relay en la red, o cuando son partes de la red (o toda la red) externalizados. En estos casos, métricas de servicio pueden

utilizarse para asegurar que están recibiendo el servicio son solicitar (y pagar) del proveedor o agente de outsourcing. Los tipos de métricas de servicio que utilizas dependerá de su diseño y los tipos de equipo (dispositivos de red) se implementa en la red, pero en este punto en el proceso de análisis, puede influir o exigir lo que se medirá en la red y (hasta cierto punto) como se os medirá. Métricas de servicio de RMA incluyen: • Confiabilidad, en términos de tiempo promedio entre fallas (MTBF) y tiempo medio entre fallos

críticos (MTBCF) • Mantenimiento, en términos de tiempo promedio para reparar (MTTR) • Disponibilidad, en términos de MTTR tiempo medio entre fallos, MTBCF, • Opcionalmente, tiempo activo y tiempo de inactividad (como un porcentaje del tiempo total),

error y pérdida de precios a distintos niveles, tales como la tasa de error de paquete, tasa de error de bit (BER), proporción de pérdida celular (CLR), proporción de células misinsertion (CMR), marco y paquete tasas de pérdida Métricas de servicio de capacidad incluyen: • Tarifas de datos, en términos de tasa de datos máxima (PDR), tarifa de datos continua (SDR) y

tarifa de datos mínima (MDR) • Tamaños de datos, incluyendo métricas de explosión tamaños y duraciones de servicio por

retraso incluyen: • Retardo extremo a extremo o ida y vuelta • Latencia de • Variación del retardo Desarrollo de métricas de servicio

Como cantidades mensurables y configurables en la red, métricas de servicio pueden ser descritos en términos de las variables en los dispositivos de red. También hay mecanismos para configurar y medir estas variables. Como vemos en el capítulo 7 sobre la gestión de red, mecanismos actuales para configurar y medir indicadores de servicio se encuentran en plataformas de gestión de red que utilizan el Protocolo simple de administración de red (SNMP) y el protocolo de información de gestión común (CMIP), los cuales acceder a las variables descritas en bases de datos de gestión, o MIB. MIBs describen las variables de gestión genéricos y específicos de la empresa. Ejemplos de variables utilizadas como indicadores de servicio: • Bytes de entrada/salida (por interfaz)

• Paquetes IP de entrada/salida (por interfaz) • Cayó Internet control mensaje protocolo (ICMP) mensajes/unidad de tiempo (por interfaz) • Métricas de acuerdo de nivel de servicio (SLA) (por usuario)

• Límite de capacidad • Tolerancia de explosión • Retardo de • Tiempo de inactividad

3.3.1 Herramientas de medición Además de los protocolos de administración y MIB, podemos utilizar herramientas comúnmente disponibles a medida servicio métricas. Una tal herramienta es la utilidad ping (disponible en versiones TCP/IP), que mide aproximadamente ida y vuelta retrasos entre las fuentes y destinos en la red. Otra herramienta es pathchar (disponible en ee.lbl.gov), que combina retardo de ida y vuelta y las medidas de capacidad por enlace con rastros de camino, como otro popular utilidad traceroute. Otra herramienta popular para analizar el tráfico TCP es TCPdump. También hay empresas propietarias, y específicos de tecnología herramientas que pueden utilizarse además de las descritas aquí. Por ejemplo, un método para monitorear la disponibilidad en la red es utilizar ping para estimar la demora y pérdida de paquetes (véase figura 3.6). Ping nos dice que el retraso de ida y vuelta aproximado, así como cuando echo ICMP paquetes (paquetes de ping) se pierden en la red o en el destino. Mientras que no es un método exacto, es bastante simple de configurar y utilizar y proporciona un mecanismo de alerta temprana para problemas RMA.

Figura 3.6 usar Ping y pérdida de paquetes IP como servicio métricas para RMA

Métricas de servicio

Donde se medirán en sistema métrico

Método de medición

1

Retraso de LAN

Entre dispositivo de NM y cada Router en LAN

Ping

2

WAN retardo 1

Entre dispositivo de NM y la interfaz Local del Router para WAN

Ping

3

Retraso WAN 2

Entre NM dispositivo y el Router remoto Interfaz WAN

Ping

En cada Router Local

SNMP

4

Pérdida de paquetes de la LAN

Figura 3.7 ejemplo servicio métricas

En el desarrollo de métricas de servicio, también queremos tratar de determinar que en el sistema que queremos medir cada métrica, así como los posibles mecanismos para la medición, como en la figura 3.7.

3.3.2 Dónde aplicar métricas de servicio Donde se aplican los indicadores de servicio está determinada en parte por lo que planea lograr de ellos (p. ej., separación de responsabilidades). Son útiles cuando se trata de aislar y localizar problemas en la red, especialmente cuando hay múltiples grupos responsables de la red. Por ejemplo, en la figura 3.6, las métricas de servicio Caracterizar el comportamiento

que se aplican puede utilizarse también para separar responsabilidades entre un proveedor de end-to-end, un proveedor de servicios WAN y otros proveedores de intermedios.

3.4 Caracterizar el comportamiento Caracterización de comportamiento significa que representa cómo los usuarios y aplicaciones utilizan la red, para desarrollar y comprender sus necesidades. Estas representaciones pueden ser muy simples, que comprende las estimaciones de duración de la sesión de usuario, el número de sesiones activas y tamaños de datos; o pueden ser complejos y detallados modelos de comportamiento de usuario y aplicación. El objetivo de caracterizar el comportamiento de nuestra red es determinar si podemos estimar requerimientos de performance de la red a través de la comprensión de cómo los usuarios y las aplicaciones se comportan en toda la red. En esta sección examinamos algunas de las características de los usuarios y aplicaciones que pueden utilizar para modificar y mejor estimar requisitos de rendimiento de red. Luego aplicamos estas características de usuario y aplicaciones durante el proceso de análisis de flujo. Los tipos de comportamiento que examinamos son: • Comportamiento de los usuarios

• Comportamiento de la aplicación • Comportamiento de la red

3.4.1 Modelado y simulación Desarrollo de modelos o simulaciones de usuario, aplicación y comportamiento de la red es a menudo útil en predecir, determinar o estimar flujos de datos y requisitos. Los modelos pueden variar desde aproximaciones fáciles, simplistas, de primer orden altamente complejo y desperdiciador de tiempo. Lo que se obtiene de un modelo o una simulación depende de la cantidad de tiempo y esfuerzo que pones en él. Modelado y simulación son útiles durante todo el proceso de análisis para la caracterización de usuario, la aplicación y la existente red de comportamientos. También son útiles durante los procesos de diseño y arquitectura para entender el comportamiento espacial y temporal de los flujos de tráfico, así como entender el tipo de equipo, ubicación, configuración y comportamiento bajo estrés o fracaso. Figura 3.8 se muestra una simulación de ejemplo de una red simple. Este ejemplo muestra varios dispositivos conectados a una red de medios compartidos y se basa en un modelo desarrollado para mostrar características de funcionamiento de esta red bajo estrés.

Utilización capacidad de rendimiento rendimiento (rendimiento)

Figura 3.8 simulación del comportamiento del rendimiento de red

Las exhibiciones en esta muestra de la figura los resultados de pruebas de rendimiento ejecutan en esta simulación. Rendimiento de procesamiento, utilización y retardo se muestran gráficamente en el tiempo para representar el comportamiento temporal de la red. Modelos y simulaciones se pueden desarrollar utilizando herramientas propietarias o disponibles para el público. Una ventaja de tener estos modelos es que, una vez desarrollados, pueden ser utilizados una y otra vez para ayudar a afinar el sistema para un rendimiento óptimo. Así, aunque tales modelos y simulaciones pueden tomar tiempo y esfuerzo a desarrollar, su recuperación con el tiempo puede ser sustancial. Caracterizar el comportamiento

3.4.2 Comportamiento de los usuarios Junto con la identificación de indicadores de servicio para nuestra red, es útil para entender cómo los usuarios del sistema aplicarán usos. Patrones de uso simple pueden incluir tiempos de trabajo del usuario y las duraciones; y para cada aplicación el número total de usuarios, la frecuencia que un usuario espera tener una sesión de aplicación funcionando (generalmente como número de sesiones por usuario, por día), cuánto tiempo promedio dura sesión de aplicación (generalmente del orden de minutos) y un estimación del número esperado de sesiones de usuario simultáneas para esa aplicación.

La lógica aquí es que podemos desarrollar una regla de oro para escalar el rendimiento esperado de la red mediante el examen de comportamiento de usuario y aplicación. Figura 3.9 muestra las características de cómo un usuario utiliza una aplicación. Este es un ejemplo de una aproximación simple, de primer orden del comportamiento del usuario y aplicación. En esta figura se describe una sesión de aplicación por algunas características comunes. En primer lugar, las sesiones se muestran con los tiempos que la sesión está activa (como cajas). El tamaño de cada cuadro indica la duración de la actividad y el número de cajas por unidad de tiempo indica

Figura 3.9 Caracterización del comportamiento de los usuarios

la frecuencia de la actividad. También se muestra en esta figura es el número de sesiones simultáneas que están activos en un momento dado en el tiempo. Estimar la frecuencia y duración de las sesiones de aplicación y el número de sesiones simultáneas permite aplicar un modificador a los requisitos de funcionamiento para cada aplicación (o al menos las aplicaciones que considere lo suficientemente importante como para caracterizar ). Por ejemplo, si usted puede estimar el número de sesiones simultáneas para una aplicación, esa estimación puede utilizarse como un multiplicador para el requisito de la capacidad de la aplicación. Del mismo modo, si usted sabe la duración de una sesión de aplicación, puede utilizar para ayudar a estimar la cantidad de tiempo de servicio para que la aplicación tendrá que ser configurado dentro de la red.

3.4.3 Comportamiento de la aplicación También es útil determinar el comportamiento de las sesiones de aplicación. Junto con el comportamiento de los usuarios, comportamiento de la aplicación puede ayudar a modificar los requisitos de rendimiento para lograr una mejor estimación de qué servicios y prestaciones que usted necesita para su red. Caracterizar el comportamiento de la aplicación que desea considerar los tamaños de datos que la aplicación de proceso y pasar a través de la red; la frecuencia y duración de datos ser pasado a través de la red; cualquier características de flujo de tráfico se puede obtener para la aplicación, como las direcciones de flujo (por ejemplo, desde cliente a servidor); y los requisitos para multidifusión (incluyendo las emisiones). En la aplicación de comportamiento del usuario y la aplicación puede ir desde una aproximación bastante sencilla a un modelo muy complejo. Por ejemplo, puede hacer algunas suposiciones de simplificación en cuanto a patrones de uso y comportamiento de la aplicación. Un modelo simple es asumir que habrá sólo una sesión de una aplicación activa en cualquier momento. Otro modelo es aplicar fórmulas estadísticas para el comportamiento de patrón y aplicaciones de uso. Esto puede ser absolutamente acertado cuando la aplicación está bien entendido, como en aplicaciones de telefonía. Mientras que usted puede intentar caracterizar el comportamiento de todos los usuarios y aplicaciones para la red, generalmente obtener el mayor beneficio al aplicar este análisis a lo más importantes (misión crítica, velocidad crítica, en tiempo real, interactivo, alto rendimiento) aplicaciones y sus usuarios, como sus requisitos por lo general conducen la arquitectura de red y el diseño. Mientras que la caracterización de patrones de uso y comportamiento de la aplicación puede ser difícil y desperdiciador de tiempo, usted encontrará

que hacer tanto ayuda a su comprensión de los requisitos del sistema y cómo aplicarlas. Sin embargo, debe asegurarse que usted puede permitirse el tiempo y esfuerzo que tomará. Desde mi experiencia personal, he visto rápidos aproximaciones de primer orden

desarrollado en días y complejos, detallados modelos y simulaciones que han tenido meses para refinar. Sin embargo, se pueden hacer muchas buenas aproximaciones del orden de unas pocas semanas.

3.5 Desarrollo de requisitos de RMA Ahora expandiremos sobre los requisitos de rendimiento discutidos previamente, desarrollo y cuantificación de necesidades siempre que sea posible. En esta sección se discuten dos tipos de umbrales: general y entorno específico. Los umbrales generales son aquellos que se aplican a la mayoría o todas las redes. Son reglas generales que han sido determinadas a través de experiencia para trabajar en la mayoría de los ambientes. Se aplican cuando no hay umbrales específicos de medio ambiente a utilizar. Umbrales específicos de medio ambiente están determinados por el medio ambiente del proyecto de red actual que está trabajando. Son específicas de ese entorno y por lo general no son aplicables a otras redes. Estos umbrales son útiles en la distinción entre alto y bajo rendimiento de la red.

3.5.1 Fiabilidad Fiabilidad es un indicador estadístico de la frecuencia de falla de la red y sus componentes y representa las paradas no programadas del servicio. Una medida de confiabilidad es el tiempo medio entre fallos críticos (MTBCF), normalmente expresado en horas. Una medida relacionada es el tiempo medio entre fallos (MTBF), que considera todas las fallas, independientemente de su importancia en el momento del fallo y es una aproximación conservadora, útil en sistemas simples. MTBF puede confundir el diseñador de un sistema complejo. Como sistemas se vuelven más complejos y limitaciones de recursos restringen el grado de diversidad o la compra de componentes de mayor fiabilidad, el uso de la MTBCF se convierte más esclarecedor, aunque tarda más cuidadoso análisis, centrándose en el sistema rendimiento durante las situaciones de misión específica. MTBF se calcula como el inverso de la tasa de fallos, que se estima a través de pruebas o análisis en términos de fracasos por horas de funcionamiento. Criticidad se tomó en cuenta al considerar las tasas de fracaso de sólo los componentes que son críticos para la misión. En la superficie, confiabilidad aritmética es un poco confuso; Recuerde que los cálculos para la confiabilidad de los sistemas realmente se realizan agregando las tasas de fracaso (fallas por hora) de los componentes y luego invertirlos.

3.5.2 Capacidad de mantenimiento Mantenibilidad es una medida estadística del tiempo a restaurar el sistema al estado de funcionamiento, una vez que ha experimentado una falla. Esto se expresa generalmente como tiempo promedio para reparar (MTTR). Reparación de un fallo del sistema consiste en varias etapas: detección, aislamiento de la falta de un componente que puede ser sustituido, el tiempo necesario para entregar las piezas necesarias para la ubicación del componente fallido (tiempo de

logística) y el momento de realmente cambiar el componente, probarlo y restaurar el servicio completo. Tiempo medio de reparación generalmente asume que el logística el tiempo es cero; se trata de una hipótesis, que no es válido si un componente debe ser sustituido para restaurar el servicio tarda días en obtener.

3.5.3 Disponibilidad de Disponibilidad (también conocido como disponibilidad operacional) es la relación entre la frecuencia de la falta de misión crítica y el tiempo para restaurar el servicio. Se define como el tiempo medio entre fallos críticos (o tiempo medio entre fallos) dividido por la suma del tiempo medio de reparación y el tiempo promedio entre fallas críticas o tiempo medio entre fallos. Estas relaciones se muestran a continuación, donde A es la disponibilidad. A = MTBCF/MTBCF + MTTR o = MTBF/MTBF + MTTR Algunas consideraciones importantes en la evaluación de la disponibilidad a menudo son pasados por alto. En primer lugar, la disponibilidad no necesariamente refleja el porcentaje de tiempo que el sistema es operacional; mantenimiento programado no es tomado en cuenta en este cálculo, sólo mantenimiento no programado. Esto es significativo porque mantenimiento programado no penalizar el sistema ya que puede realizarse cuando los componentes no son necesarios para llevar a cabo a la misión. Nuestra preocupación real es la naturaleza de la sorpresa de fallas en el sistema, que se refleja en la disponibilidad. Analizar la disponibilidad de la red nos da la capacidad de programar el mantenimiento preventivo y reemplazar con frecuencia componentes de falla en un intervalo mayor que la tasa de fracaso, aumentando así la fiabilidad del sistema en general. Otra forma de mejorar la disponibilidad es reducir el tiempo medio de reparación, ya sea a través de la diversidad o capacidades de reemplazo acelerado. Varias formas de lograr la diversidad incluyen la instalación de capacidades de conmutación automático para componentes críticos que ellos automáticamente cambian a una unidad redundante en milisegundos una vez que se detecta una falla; sin embargo, cambio automático es una característica cara a añadir a estos sistemas. Si la presión de servicio no garantiza este nivel de gasto, soluciones de recambio rápido pueden mejorar MTTR substancialmente sobre los procedimientos tradicionales de solución de problemas y reparación: sustitución en caliente que puede cambiarse manualmente mucho acelera el restauración de servicios, como almacenamiento de componentes de repuesto en proximidad a la ubicación del componente crítico. Otras medidas de disponibilidad incluyen uptime, downtime y las tasas de error y pérdida. Tiempo activo y tiempo de inactividad Una medida común de la disponibilidad se expresa en términos de porcentaje de uptime o tiempo de inactividad. Por ejemplo, una solicitud de propuesta (RFP) de un cliente potencial puede indicar un necesario uptime de 99,999% (conocido comúnmente como "cinco nueves"), pero ¿qué significa realmente eso? ¿Qué los términos tiempo activo y tiempo de inactividad realmente significan? Cuando la disponibilidad es representada como un porcentaje de uptime o tiempo de inactividad, se mide por semana, mes o año, basado en la cantidad total de tiempo para ese período. Uptime es cuando el sistema (aplicaciones, dispositivos, redes) está disponible para el

usuario (en este caso, el usuario puede también ser un dispositivo o aplicación). Por disponibles, nos referimos a la gama de tener conectividad básica para realmente ser capaz de ejecutar aplicaciones en toda la red. Como esto se describe en el análisis de requerimientos es importante cómo será medido y verificado. Asimismo, tiempo de inactividad puede variar desde no poder conectarse a través de la red, para tener conectividad pero con pérdida de tasas bastante altas (o capacidad bastante baja) que aplicaciones no funcionan correctamente. Figura 3.10 muestra algunos comúnmente usados porcentajes de disponibilidad (como porcentaje del tiempo de actividad), que van desde 99% a 99.999%. % Tiempo de actividad

99% 99.9% 99.99% 99.999%

Cantidad de tiempo de inactividad permitido en Horas (h), minutos (m) o segundos (s) por un periodo de tiempo Anual

Mensual

Semanal

Diario

87.6 h

7.3 h

1.68 h

14.4 m

8.76 h 53 m 5.3 m

44 m 4.4 m 26.3 s

10 m

1.4 m

1m

8.6 s

6s

0.86 s

Figura 3.10 Uptime medido sobre períodos de tiempo diferentes

Otra forma de ver la disponibilidad es por cuánto tiempo de inactividad puede tolerarse por un periodo de tiempo. La gama se muestra en la figura 3.10, 99%, a 99.999%—covers la mayoría de los requisitos de tiempo de actividad solicitada. En el extremo inferior de esta gama, 99% permite que el sistema que por un poco de tiempo (más de 87 horas al año). Esto puede ser aceptable para los prototipos demostradores o sistema pero es inaceptable para la mayoría de los sistemas operativa. Cuando los proveedores de servicios comerciales ofrecen uptime en el extremo inferior de esta gama, esto debe tenerse en la disponibilidad global de la red. Un nivel de uptime de 99.99% está más cercano de donde realmente operan la mayoría de los sistemas. En este nivel se permite 1 minuto de tiempo muerto por semana, que equivale a unos transeúntes por semana, o una menor interrupción por mes (donde un transitorio es un evento de breve duración red [del orden de segundos], como el tráfico se reencamina, o un periodo de congestión). Muchas redes que alguna vez tuvieron requisitos de tiempo de actividad inferior al 99.99% ahora dependen de la red mucho más y son revisar requisitos de uptime 99.99% o superior. A 99.999%, mayoría de los sistemas empiezan a empujar sus límites operacionales. Este nivel de desempeño, lo que indica que la red se invoque altamente (por ejemplo, para aplicaciones de misión crítica), afectará la arquitectura de red y el diseño en varias áreas, como se explica en capítulos posteriores. Finalmente, un tiempo de actividad más allá de 99.999% aborda la actual franja de rendimiento, donde el esfuerzo y los costos para soportar un alto grado de tiempo activo pueden dispararse. Incluso hay algunas aplicaciones que no pueden tolerar ningún tiempo de inactividad en todos mientras que en la sesión. Para estos tipos de aplicaciones, uptime es 100% mientras que en la sesión. Un ejemplo de una aplicación es el control remoto de un evento (por ejemplo,

pilotando un vehículo, realice una operación), en tiempo de inactividad puede resultar en una pérdida de la pérdida del vehículo o posible de la vida (uno de los criterios para una aplicación de misión crítica). En casos como este, sin embargo, los tiempos de alta disponibilidad son a menudo conocidos con anticipación (prevista) y pueden planificarse para. En este punto debemos señalar que muchas interrupciones en el sistema son muy breves en el tiempo (transitorios) y no pueden afectar a los usuarios o sus aplicaciones. En algunos casos los usuarios pueden no saben que existe un problema, como la interrupción puede manifestarse sólo como una pausa en una aplicación. Sin embargo, tales eventos son parte de la estimación de la fiabilidad, especialmente en redes donde hay límites estrictos en fiabilidad. Por lo tanto, mientras que un tiempo de inactividad semanal de 10 minutos (o 99.9% uptime) sería sensible (por ejemplo, sesiones de aplicación cayendo) si ocurrió una vez, realmente puede ser una distribución de varios transitorios de 15 segundos, cada uno de ellos resulta en aplicaciones estancamiento durante varios segundos. Con esta información y la tabla anterior de uptime estima podemos presentar un umbral general de tiempo de actividad. El umbral general de tiempo de actividad, basado en la experiencia práctica, es del 99,99%. Cuando aplicar este umbral general, requisitos de tiempo de actividad inferior al 99.99% se consideran de bajo rendimiento y requisitos de tiempo de actividad mayores o iguales a 99.99% son considerados de alto rendimiento. Recuerde que este umbral general se utiliza en la ausencia de cualquier umbrales específicos de medio ambiente que pueden ser desarrollados para su red como parte del proceso de análisis de requisitos. Medición de tiempo de actividad Al principio de esta sección nos preguntamos "¿Qué es eso (99.999% uptime) realmente?" En el capítulo 1, los requisitos para servicios incluyen que sean configurables, medibles y verificables en el sistema. ¿Este es uno de los mayores problemas con un requisito de porcentaje de uptime o tiempo de inactividad: Cómo puede ser configurado, medido o verificado? ¿En términos de tiempo de actividad de medición esta pregunta se puede pedir en tres partes: cuando debe ser medido (frecuencia), donde debe medirse, y cómo debe medir (métricas de servicio)? Primero consideremos la frecuencia de medición. Un problema de expresar el tiempo de actividad únicamente como un porcentaje que no incluye un factor de tiempo. Consideremos, por ejemplo, un requisito para el 99.99% de uptime. Sin un factor de tiempo, eso puede significar un tiempo de inactividad de 53 minutos al año, 4,4 minutos por mes, o 1 minuto por semana. Sin indicar un factor de tiempo, puede haber una sola interrupción de hasta 53 minutos. Mientras la interrupción sólo durante el año, puede cumplirse este requisito de la disponibilidad. Algunas redes pueden tolerar un tiempo de inactividad acumulada de 53 minutos al año, pero no podían manejar un solo tiempo de inactividad de esa magnitud. Hay una gran diferencia entre una interrupción grande y varios pequeños cortes. Que indica un factor de tiempo (frecuencia) junto con uptime hace este requisito más válido. Para redes que no pueden tolerar interrupciones grandes pueden tolerar varios cortes pequeños, uptime 99.99% medido semanalmente puede tener más sentido que simplemente 99.99% uptime. Indicando "medido semanalmente", están forzando el requisito de que las interrupciones pueden ser no más de 1 minutos totales por semana. Próximo vamos a tener en cuenta donde se debe medir el tiempo de actividad. Indicando donde se mide el tiempo de actividad es tan importante como indicando su frecuencia. Si no se dice nada acerca de donde se mide, la suposición es que cuenta con un tiempo de inactividad en cualquier

lugar de la red contra activo total. Para algunas redes de este puede ser el caso y como tal debe ser indicado explícitamente como requisito. Para muchas redes, sin embargo, el tiempo de actividad es más eficaz cuando se aplica selectivamente a las partes de la red. Por ejemplo, puede ser más importante que el tiempo de actividad general a través de uptime de servidores o dispositivos especializados

Figura 3.11 Uptime medido por todas partes

la red. Si este es el caso, debe ser incluido como parte de los requisitos de funcionamiento. Figura 3.11 muestra un ejemplo donde el tiempo de actividad se aplicaría en todas partes en la red. La pérdida de servicio a cualquier dispositivo en esta situación podría contar contra activo total. En la figura 3.12, el tiempo de actividad ha sido refinada para aplicar solamente entre cada usuario

Figura 3.12 Uptime mide selectivamente

LAN y LAN server. En este ejemplo, si el servicio se pierde entre la LAN del usuario, no contaría contra un requisito de tiempo de funcionamiento total. En nuestros dos ejemplos nos muestran una relación inversa entre ser capaz de aplicar el tiempo de actividad en todas partes y tener un preciso y una aplicación más factible de uptime. Sin

embargo, es posible, tanto que se apliquen a la misma red. Podríamos aplicar una norma en todas partes en la red y tienen otra norma que se aplica selectivamente. A menudo, tiempo de actividad se mide end-to-end, entre dispositivos de usuario (dispositivos informáticos genéricos) o entre dispositivos de red (routers, switches o estaciones de seguridad y monitoreo de red). Por ejemplo, pueden medirse end-to-end, en routerinterfaces, wheretheroutersareseparatedbymultiplenetworks. Puntos de medición incluyen la interfaz de LAN/WAN, puntos de entrada y salida del router y en las estaciones de monitoreo distribuyen por toda la red. Determinar cómo medir el tiempo de actividad es particularmente importante cuando los proveedores de servicios están integrados en el sistema o cuando los servicios son demarcados entre zonas bien definidas de la red. Por último, cómo se mide el tiempo de actividad es también importante. Como mostramos más adelante en esta sección, puede medirse en términos de falta de conectividad o como una tasa de pérdida (tarifa de error de bit, célula, marco o las tasas de pérdida de paquetes). El método se utiliza para medir impactos de la actividad cómo puede configurarse dentro de los dispositivos de red, así como puede ser verificado. En el desarrollo de sus requisitos de tiempo de actividad, tenga en cuenta que algún tiempo de inactividad en la red necesita programar, con el fin de realizar cambios en la red, actualización de hardware y software, o para ejecutar las pruebas. Tiempo de inactividad programado para mantenimiento no debe contar contra el tiempo total de funcionamiento de la red, y la cantidad de downtime planificado (frecuencia y duración) se debe incluir en su requisito de desempeño. De hecho, dado lo que especificamos donde, cuando y cómo se mide el tiempo de actividad, podemos realmente tener múltiples requisitos de tiempo de actividad en la red. Por ejemplo, puede ser un requisito general en toda la red, medida en todas partes y requisito de otro, mayor rendimiento, mide sólo entre dispositivos vitales en la red. Por lo tanto, un requisito de tiempo de funcionamiento puede parecer algo como esto: tiempo activo de red (ver figuras 3.11 y 3.12): 1. 99.99% uptime, medido semanalmente, medido en cada dispositivo de interfaz y usuario de router en la red. 2. 99.999% uptime, medido semanalmente, para el acceso a la red de granja de servidores, medida en la interfaz del router en la granja de servidores, en servidores NICs. El ping de aplicación también se utilizará para probar la conectividad entre cada usuario LAN y el servidor de LAN. 3. Tenga en cuenta que estos requisitos no se aplican a períodos de tiempo de inactividad programado para mantenimiento.

3.5.4 Los umbrales y límites Requisitos de RMA pueden incluir descripciones de umbrales o límites. Requisitos de RMA se reunió o derivados para cada una de las aplicaciones en la red de conversaciones con los usuarios de cada aplicación, así como de documentación sobre las aplicaciones y pruebas de las aplicaciones en la red o en un banco de pruebas red. De los requisitos puede a menudo determinar umbrales específicos de medio ambiente (o límites) en cada aplicación mediante el trazado de niveles de rendimiento de aplicaciones. De esto se puede determinar lo que constituye

bajo y alto rendimiento RMA de la red. En la ausencia de umbrales específicos de medio ambiente se pueden utilizar los umbrales generales presentados en este capítulo. Además, RMA garantías (si existe) para servicios y tecnologías que existen en la red actual, o que es probable que en la red planificada. Por ejemplo, servicio de Pacific Bell datos multimegabit conmutado (SMDS) tiene una disponibilidad indicada, en términos de tiempo medio entre interrupciones de servicio o mayor o igual a 3500 horas, con un tiempo medio para restaurar de menor o igual a 3,5 horas. Por otro lado, la especificación de Bellcore para Duns exige una disponibilidad del 99.9%. De nuestra discusión anterior podemos ver que tanto estas especificaciones describen características similares de la disponibilidad, con la especificación de MTBCF/MTTR siendo más específico. Algunas de las técnicas de estimación que requieren el conocimiento de que tecnologías o servicios existen o están previstos para el sistema. Desde este punto el proceso de realmente no sabemos qué tecnologías o servicios vamos a usar para nuestra red (como se determinó en la arquitectura y diseño de procesos), estas técnicas pueden usarse en las tecnologías o servicios que están en la red actual, o en un conjunto de tecnologías de candidato o servicios para nuestra red planificada. Más adelante en los procesos de diseño y arquitectura, cuando optamos por tecnologías o servicios para nuestra red, podemos aplicar la información recogida aquí para cada uno de los servicios de tecnologías. Un ejemplo de un umbral general de RMA es de tiempo de actividad. Los usuarios normalmente esperan que el sistema sea operacional como cercano al 100% del tiempo como sea posible. Uptime puede acercarse a 100%, dentro de un décimo, centésimo, o a veces una milésima parte de un por ciento, pero con ventajas y desventajas de la complejidad del sistema y el costo. Anteriormente en este capítulo

Figura 3.13 umbrales entre el Banco de pruebas, bajo y alto rendimiento activo

hemos descrito un umbral general de tiempo de actividad, basado en la experiencia y la observación, de 99.99%. En general, requisitos de tiempo de actividad que son mayor o igual a 99.99% son considerados de alto rendimiento, los que son menos del 99.99% bajo rendimiento. Además, un umbral general de aproximadamente 99.5% puede utilizarse para distinguir un requisito bajo rendimiento de prototipos y demostradores. Estos umbrales se muestran en la figura 3.13. Tenga en cuenta que cualquier umbrales específicos de medio ambiente que se desarrollan en la red se reemplazan estos umbrales generales. Tasa de error o pérdida se utiliza como una medida de tiempo de actividad. Por ejemplo, para un requisito de uptime de 99.99%, pérdida de paquetes o celdas se puede utilizar para medir este desempeño. Para muchas aplicaciones, la experiencia ha demostrado que una pérdida de paquetes de 2% es suficiente para perder sesiones de aplicaciones. Esto puede ser considerado tiempo muerto y de hecho es una medida más práctica y verificación de uptime de intentos de representación matemática.

Si usted está usando un umbral de 2% de pérdida y pérdida de paquetes en la red de medición, se cuenta como tiempo de inactividad cuando la pérdida de paquetes es mayor al 2%. 99.99% medido semanalmente, la red puede tener una mayor pérdida de paquetes o 2% durante 1 minuto por semana (vea la sección 3.5.3). Además de los umbrales arriba, garantías de funcionamiento y servicio deben aparecer también como requisitos de la aplicación. Determinar los requisitos de tiempo de actividad es un proceso iterativo. Como usuarios, dispositivos, aplicaciones y redes evolucionan, sus necesidades tendrá que ajustarse.

3.6 Requisitos de retardo en desarrollo Para aplicaciones que tienen requisitos de retardo, utilizamos los términos retardo de extremo a extremo, retardo de ida y vueltay variación de retardo como medidas de retardo en la red. Comenzamos introduciendo algunos útiles general los umbrales y límites de retraso: retraso de interacción, tiempo de respuesta humana y retardo de propagación de la red. Estos umbrales y límites son útiles en la distinción de requisitos de retardo bajo y alto rendimiento para su red. Retraso de la interacción (INTD) es una estimación de cuánto tiempo un usuario está dispuesto a esperar una respuesta del sistema durante una sesión interactiva. Aquí una sesión se define como el período de tiempo durante el cual una aplicación está activa. El retraso de la interacción depende del comportamiento de los usuarios, ambiente del usuario y los tipos de aplicaciones se utiliza. Retrasos de interacción pueden variar de 100s de milisegundos a un minuto o más. En general, una gama útil es de 10 a 30 segundos. INTD es importante al construir una red orientada a aplicaciones interactivas. Una estimación INTD es útil en la caracterización de aplicaciones que son libremente interactivas, aquellos donde se espera la espera de recibir información. Esto se aplica a aplicaciones de procesamiento de transacciones, así como Web, transferencia de archivos y algunos procesamiento de base de datos. Para aplicaciones como estas, el usuario notará cierta demora y INTD es una estimación de usuarios cuánto están dispuestos a esperar. Un límite superior a INTD es una medida del nivel de tolerancia de los usuarios. Tiempo de respuesta humana (TRH) es una estimación del límite máximo de tiempo en el que los usuarios comienzan a percibir retraso en el sistema. Así, cuando el tiempo de respuesta del sistema es menor que TRH, los usuarios generalmente no perciben ningún retraso en el sistema. Retrasos en más de terapia de reemplazo hormonal, los usuarios generalmente nota el retraso del sistema. Una buena estimación de la TRH, basado en la experiencia y la observación, es aproximadamente 100ms. Es un umbral importante retraso, ya que distingue cuando los usuarios serán o no notará el retraso en el sistema. Tenga en cuenta que cuando los usuarios demora sistema, tomen conciencia del sistema. Al diseñar la arquitectura y el diseño de una red donde uno de los objetivos es para ocultar el sistema del usuario, luego terapia de reemplazo hormonal se convierte en un requisito fundamental para el sistema. Un ejemplo de esto es en la informatización en red, donde el sistema es abstraído de los usuarios. Terapia de reemplazo hormonal es particularmente importante para aplicaciones altamente interactivas, donde los tiempos de espera no pueden o no deben ser percibidos por los usuarios. Esto suele ocurrir cuando la aplicación es compatible con un entorno interactivo para los usuarios, como en visualización, realidad virtual y aplicaciones colaborativas, pero también puede

aplicarse a aplicaciones donde retrasos del sistema superiores de terapia de reemplazo hormonal como resultado pérdida de productividad. Retardo de propagación de la red es una estimación del tiempo que tarda una señal a un medio físico o un enlace, por ejemplo, el retardo de propagación a través de un enlace de DS3. Esto proporciona un límite inferior a los retrasos de red y sistema de extremo a extremo e ida y vuelta. Retardo de propagación depende de la distancia y la tecnología. Es útil como un límite inferior de la demora, para que nos dice cuando una aplicación no funcionen bien en toda la Tiempo de respuesta humana

Retraso de la interacción

Retardo de propagación de la red

0,01 0,1 1,0 10 100 Retardo (segundos) Figura 3.14 demora las estimaciones de necesidades de los usuarios

de la red, como su requisito de retardo de propagación de red es más estricto que el retardo de propagación real o previsto de la red. Estos umbrales de retardo y los límites se muestran en la figura 3.14. Cualquiera o todas de estas estimaciones de retraso pueden aplicarse a una red. Por ejemplo, nos podemos utilizar HRT como un límite para todos los servicios, restricción de la arquitectura y el diseño para proporcionar las características de retardo de menos de HRT para esa red. O podemos elegir un valor de INTD que define y limita el servicio interactivo. En todos los casos, retardo de propagación de la red proporciona un límite inferior para el retraso. Cualquiera de estos cálculos de retraso puede usarse también como garantías en el servicio. Estas estimaciones de retraso provienen de la experiencia y se presentan aquí para que consideres. Puede no está de acuerdo con sus valores o encuentra otras estimaciones útiles de retraso. Le animamos a desarrollar sus propias estimaciones o mejora sobre los que se presentan aquí. Ya sabemos la red, sistema y medio ambiente para su proyecto de red, estás en la mejor posición para estas estimaciones se aplican a la red. Podemos utilizar las estimaciones para la terapia de reemplazo hormonal y INTD para ayudarnos a distinguir entre aplicaciones interactiva explosión e interactivo a granel . Cuando tanto la capacidad de respuesta de la aplicación (cómo con frecuencia y rápidamente la aplicación interactúa con el usuario) y el retraso extremo a extremo o ida y vuelta (lo que sea para medir el sistema) están limitados por una de estas características de retardo, estiman que la aplicación es interactiva ráfaga o interactivo a granel. En Figura 3.15 HRT y INTD se utilizan como límites para separar el burst interactivo y aplicaciones interactivas a granel. Entre estos demora dos estimaciones, que van desde 100ms hasta 10-30 segundos, es un área gris donde podría considerarse la aplicación explosión interactiva o a granel interactivo. El uso de INTD y terapia de reemplazo hormonal es probablemente la forma más sencilla para distinguir entre ráfaga interactivo y aplicaciones interactivas a granel.

Tiempo Retardo (segundos) Figura 3.15 regiones de rendimiento para aplicaciones a granel ráfagas e interactivo interactivo

3.6.1 Demoras de extremo a extremo e ida y vuelta Demoras de extremo a extremo e ida y vuelta se componen de muchas fuentes de retardo, incluyendo propagación, colas, transmisión, entrada-salida, cambio y transformación. Mientras que sería útil poder monitorear y medir cada fuente de retraso, no es práctico para la mayoría de las redes. Por lo tanto, se utilizan los totales como retardo de extremo a extremo e ida y vuelta. Para muchas redes, especialmente redes IP, el retardo de ida y vuelta se mide utilizando diferentes versiones de la utilidad ping. Ping proporciona una forma útil, fácilmente medibles y fácilmente disponible de retardo de ida y vuelta. Recordemos que hemos utilizado THS, INTD y retardo de propagación de la red como umbrales y límites para distinguir entre niveles de desempeño para los requisitos de retardo. Se basan en combinaciones de: • Límites físicos de la red, por ejemplo, el tamaño de la red y las distancias entre aplicaciones,

usuarios y dispositivos • Rendimiento de hardware y software de dispositivo • Funcionamiento del Protocolo de red • Comportamiento de la aplicación en los umbrales de retardo determinado • Interacción del usuario con el sistema en los umbrales de retardo determinado

Una guía para los requisitos de retardo en desarrollo consiste en determinar el factor limitante de los límites y los umbrales de retardo. El factor limitante será el cuello de botella del retraso final dentro del sistema. Como factores limitantes se encuentran, a menudo puede ser reducidos o eliminados, revelando la siguiente limitación del factor. Este proceso se repite hasta que se encuentra una limitante que no puede ser reducido o eliminado, o hasta sistema retardo es en un nivel aceptable. Dado que los límites físicos retraso son límites absolutos (la velocidad de la radiación electromagnética a través de diversos medios de comunicación es bien conocida), pueden afectar o negar otros umbrales de retardo. Por ejemplo, si una aplicación requiere un retardo de ida y vuelta de 80ms para apoyar un ambiente de realidad virtual interactiva (VR), y la sesión de aplicación está siendo distribuida entre Los Ángeles y Tokio, el ida y vuelta retardo de la red ( aproximadamente 120ms) superará el requisito de demora de aplicación, independientemente de la arquitectura de red y el diseño. Por lo tanto, la aplicación tiene que tener en cuenta el retardo de ida y vuelta entre Los Angeles y Tokio, posiblemente modificando el código, algoritmos o modelo de uso, o las sesiones de aplicación no pueden ser distribuidas entre estos sitios. Sabiendo esto temprano en el proceso de la arquitectura permite a los desarrolladores de aplicaciones o ingenieros de red para adaptarse a los límites físicos de la red.

Ahora vamos a decir que se reduce la distancia de la red arriba y la limitación física sobre la demora ahora es 10 ms (por ejemplo, la red está ahora entre Los Ángeles y San Francisco). Sin embargo, a través de pruebas de la aplicación de la red actual, se espera un retardo de ida y vuelta de 100ms dentro del sistema (principalmente debido a los dispositivos utilizados). ¿Qué puede hacerse? Rendimiento de hardware y software del dispositivo puede ser muy difícil de identificar, comprender y mejorar. En la arquitectura y el diseño de una red necesitamos tratar a considerar cada pieza en el path end-to-end de comunicaciones (flujos de tráfico), que pueden consistir en una variedad de dispositivos. ¿Qué buscamos que reducirá las fuentes probables de retraso en el sistema, sin una cantidad razonable de tiempo, esfuerzo y costo? Las áreas que busque fuentes de retardo que puede ser modificado o ajustado son computadora OSs, protocolos de red y dispositivos periféricos. Lo que nos podemos mirar en estas áreas son OSs que son notoriamente lentos y mal escritas, protocolos que se aplican mal, y dispositivos o periféricos que se unió mal o mal configurados. Obviamente, este tipo de información no vendrá de los fabricantes pero puede encontrarse a menudo en las listas de correo, grupos de noticias, pruebas independientes e investigación académica, las cuales son cada vez más disponibles a través de la Web. Haciendo algunas investigaciones, puede rápidamente aprendes mucho sobre problemas de rendimiento con dispositivos. Hacer su propio análisis y observaciones y sacar sus propias conclusiones. Como veremos más adelante en este libro, servicios de soporte como gestión de red, enrutamiento y seguridad también desempeñan un papel en el retardo de red. Los umbrales de retardo basados en la interacción de usuario y el comportamiento de aplicación son generalmente más flexibles que los retrasos físicos o dispositivo. Hay que recordar que los valores de INTD y terapia de reemplazo hormonal son estimaciones (rango estimado de INTD), así que hay cierta flexibilidad para adaptar a su entorno. Mientras que en el ejemplo anterior el retardo físico ida y vuelta fue el último límite, cuando se redujo la distancia de la red para que el retardo de ida y vuelta fue del orden de 10 ms, el comportamiento de la aplicación (entorno interactivo de VR), con su retraso de 40ms requisito, puede ser el factor limitante. Si esto es aceptable a los usuarios, entonces las estimaciones de retraso (desde nuestra vista de alto nivel) optimizadas para que el medio ambiente.

3.6.2 Variación del retardo Variación del retardo se junta a menudo con retardo extremo a extremo o ida y vuelta a un requisito de desempeño de demora total para las aplicaciones que son sensibles a la vez ligeramente de la información. Algunos ejemplos de estas aplicaciones son las que producen o utilizan información de vídeo, audio y telemetría. Variación del retardo juntada con demora extremo a extremo o ida y vuelta, cuando no existe información sobre el requerimiento de la variación de retardo, una buena regla del pulgar es utilizar 1 a 2% de la demora de extremo a extremo como la variación del retardo. Por ejemplo, una estimación de la variación de retardo (en ausencia de cualquier requisito conocido), cuando el retardo de extremo a extremo es 40ms, es aproximadamente de 400 a 800 microsegundos. Sin embargo, sería una aproximación áspera y se debe verificar si es posible.

3.7 Desarrollo de requisitos de capacidad

En la evaluación de los requerimientos de capacidad de aplicación que queremos considerar aplicaciones que requieren grandes cantidades de capacidad, así como aquellas que requieren un valor específico (máximo, mínimo, sostenido) o un rango de capacidades. Cuando una aplicación requiere una gran cantidad de capacidad, es importante saber cuando la aplicación tiene un verdadero requisito (medible, verificable) de alta capacidad y cuando él (o el protocolo de transporte que está utilizando) simplemente intentará utilizar todo lo que la capacidad está disponible. Aplicaciones que usan TCP como su mecanismo de transporte, sin condiciones adicionales o modificaciones de los protocolos de capa más alta (o de la propia aplicación), reciban sus prestaciones basados en el estado actual de la red (es decir, mejor esfuerzo). Esto se hace por comunicarse y ajustar los parámetros de transmisión de TCP (a través del canal de control TCP entre los dos dispositivos en la sesión TCP) durante toda la sesión TCP en reacción a las condiciones de aparente congestión en la red.

3.7.1 Estimación de índices de datos Estimar un dato (o tal vez más exactamente, información) tarifa se basa en cuánta información usted sabe acerca de las características de transmisión (p. ej., circulación)

Desarrollo de requisitos de capacidad

de la aplicación y cómo precisa la estimación debe ser. Tarifas de datos comúnmente utilizados incluyen la tasa de datos máxima (PDR), tarifa de datos continua (SDR), tarifa de datos mínima (MDR) o combinaciones de éstos. Estas tarifas de datos se pueden medir en una o más capas de la red (por ejemplo, física, enlace de datos, red, transporte o sesión). Las tarifas de datos de todas las aplicaciones están limitadas por algún factor limitante. Esto puede ser la propia aplicación, o puede ser que la velocidad de la línea de la interfaz de red en el dispositivo la aplicación se está ejecutando. O sea el nivel de rendimiento de un servidor que utiliza la aplicación. Así que la verdadera pregunta es donde los límites están en el sistema para esa aplicación. Si la aplicación es compatible con una tasa muy rápida de datos (que puede ser determinada mediante la ejecución de la aplicación en una red de prueba), entonces usted puede ir a través de un proceso de eliminación para determinar qué componente, en este aparato o en algún otro, está actuando como el rendimiento cuello de botella. En un sentido, esto es una optimización local de la red. En este caso están haciendo para una sola aplicación en un entorno de red cerrada. Muchas aplicaciones se basan en el protocolo de transporte, como TCP, para proporcionar un "tan rápido como sea posible" de datos de tarifa. Tenemos una sensación intuitiva para algunas de estas aplicaciones (por ejemplo, FTP, telnet), por ejemplo, podemos estar bastante seguros de que una sesión de telnet no tendrá una tarifa de datos de 100Mb/s; Además, una sesión FTP no se debe ejecutar a 10Kb/s si se dispone de mayor capacidad.

Lo que podemos hacer para calcular tarifas de datos para aplicaciones es considerar sus tamaños de datos y tiempos de ejecución estimados. Tamaños de datos y tiempos de ejecución se basan en lo que los usuarios puede esperar o se puede medir en la red. Teniendo una aplicación que tiene características de capacidad y retardo de nebulosas, como acceso Web, se puede estimar una tarifa de datos de tamaños de datos y aplicación-suministrada por el usuario y la terminación de las épocas (por ejemplo, INTD). Podemos pedir a un número de usuarios para ver ejemplos de páginas que esperan para acceso o información que se descarga, y cuánto están dispuestos a esperar para cada evento. De esta información podríamos crear entradas en una tabla como la siguiente (Figura 3.16). De cálculos como los de la figura 3.17, podemos calcular los límites superior e inferior para tasas de datos de una aplicación, o un promedio. Para otros usos de las características de las transferencias de datos pueden ser mejor conocidas, como los tamaños de los conjuntos de datos que se transfieren así como la frecuencia y duración de dichas transferencias. Esto puede ser para aplicaciones basadas en transacciones, tales como procesamiento de tarjeta de crédito, aplicaciones bancarias y computación distribuida. Considere una aplicación informática interactiva remota que se conecta a tiendas y procesa la información del cliente, tales como entradas de tarjeta de crédito. Podemos considerar un evento (tarea) como el procesamiento de información de tarjeta de crédito de un cliente único. Entonces, el tiempo de finalización de la tarea es del orden de INTD Aplicación

Medio tiempo (segundos)

Datos promedio tamaño (Bytes)

Distribuido de computación (lotes)

103

107

Transacciones Web

10

104

Las entradas y consultas de base de datos

2–5

Entradas nómina

10

102

Teleconferencia

103

105

103

Tiempos de ejecución de la figura 3.16 y tamaños de datos para aplicaciones seleccionadas

Figura 3.17 ejemplo de una red compartida, multiprocesador Computing

anteriormente, aproximadamente 10 a 30 segundos, aunque puede esperarse por los usuarios (personal de la tienda) para ser mucho más pequeña, dicen que del orden de 5 a 10 segundos, y el tamaño de los datos para cada tarea es bastante pequeño, del orden de 100 a 1000 bytes. Otro ejemplo es un entorno en el que múltiples dispositivos comparten el procesamiento de una tarea. En cada iteración de la tarea, los datos se transfieren entre dispositivos. Aquí podemos saber la frecuencia de transferencia de datos, el tamaño de cada transferencia (que puede también ser constante), y cuánto tiempo es necesaria para procesar los datos (que pueden indicar cuánto tiempo puede tardar una transferencia). Una red de computación compartida, multiprocesador se muestra en la figura 3.17. Para algunas aplicaciones son bien conocidas las características de capacidad, y estimar un índice de datos puede ser relativamente fácil de hacer. Aplicaciones que implican voz o

Figura 3.18 envolvente de rendimiento con umbrales genéricos

Video generalmente conocen los requerimientos de capacidad. Las tarifas de este tipo de aplicaciones suelen ser constante, por lo que su pico y tarifas de datos mínimos son los mismos, o habrá un rango conocido de valores. Por ejemplo, un parámetro restringido de bajo nivel MPEG-2 bitstream (CPB) tendrá una velocidad de 4Mb/s, o un CPB nivel principal tendrá una tasa de entre 15 y 20Mb/s. Actualmente no hay general umbrales o límites en la capacidad, para determinar capacidad de bajo y de alto rendimiento. No es obvio por qué esto debería ser así, salvo que RMA y retraso tienen un impacto directo sobre la percepción del usuario del rendimiento del sistema, mientras que capacidad tiene un impacto secundario por que afectan a RMA y retraso. A menudo habrá, sin embargo, los umbrales y específicas del entorno en la capacidad, determinación de baja y de alto rendimiento para esa red. Los umbrales de rendimiento genéricos pueden agregarse a la envolvente de desempeño que hemos desarrollado en el capítulo 1. Estos umbrales, tal como se muestra en la figura 3.18, se utilizan para separar la envoltura en regiones de bajo y alto rendimiento. Esto nos da una interpretación visual de los requisitos de desempeño relativo para nuestra red y se puede utilizar para relacionar los requisitos de desempeño a la gestión.

3.8 Desarrollo de requisitos de rendimiento suplementario Tres prescripciones adicionales fueron introducidos en el capítulo 2: idoneidad operativa, soporte y confianza. Estos requisitos de rendimiento

Operaciones y soporte

Operaciones de

Apoyo

Gestión

Gestión

Personal

Soporte de mantenimiento

Herramientas

Documentación técnica

Consumibles

Almacenamiento de información

Transporte

Suministro de apoyo

Arrendamiento financiero

Modificaciones

Instalaciones Figura 3.19 elementos de operaciones y soporte

son parte del conjunto global de las operaciones y elementos que se muestra en la figura 3.19. Conveniencia operativa es una medida de cómo nuestro diseño de red puede configurar, supervisar y ajustado por los operadores del cliente.Capacidad de soporte es una medida de qué tan bien el cliente puede mantener el sistema funcionando, ya diseñado, durante toda la vida del sistema. La confianza es una medida de la capacidad de la red para ofrecer los datos sin errores o pérdida en el rendimiento requerido.

3.8.1 Conveniencia operativa Asegurando que su cliente pueda funcionar la red planificada rara vez es una tarea fácil y es que el cliente nunca piensa hasta que pide. Dos factores principales influyen en la aptitud operacional: red de arquitectura y diseño y la calidad de los operadores humanos. Es posible desarrollar una red que no puede funcionar constantemente y con eficacia. Complejos ajustes de minuto a minuto pueden inundar incluso el personal más competente. La falta de instrumentos eficaces de vigilancia o sistemas de control para integrar acciones en sitios geográficamente dispersos puede transformar el diseño más avanzado en una masa disfuncional de cables y ordenadores y recriminaciones y pleitos. Desarrollo de la red debe considerar la administración de red que permite a los operadores a ajustar la red y volver a configurar cuando necesita. Si necesitan hacerlo cada pocos minutos, gestión de red debe ser fácil de operar y debe presentar los controles de una manera fácil de entender. Un personal de operaciones si se puede usar rápidamente hacia fuera y frustrado por una red que requiere cuidado constante y preciso. Componentes que no necesitan ajuste excepto cuando se instalan no necesita desorden la consola de control integrado. Sistema de monitoreo es esencial para ajustar el rendimiento del sistema por sus operadores; muestra debe ser accesible, y los datos mostrados deben usar representaciones wellunderstood. Debe existir una consola de operaciones único (o redundante) o debe operarse el sistema desde cualquier navegador Web en la red? ¿A qué grado es la automatización incorporada para reducir la carga de trabajo de los operadores o para mejorar la respuesta a las cambiantes condiciones sobre lo que un humano puede proporcionar? ¿Es tan infrecuente que ningún sistema de control integrado se requiere regulación del sistema? Estos temas se discuten en detalle en el capítulo 7. Un coronel de la marina que dirigió un programa de desarrollo principales del sistema mantiene un cuadro en su pared del más patético, ser recluta de marina que había visto. Este "sad sack" estaba de pie en un patio de armas vacía sosteniendo una bolsa de basura en una mano y un palo con un clavo en la otra para recoger el papel del suelo. El título leyó, "recuerda. No importa lo que

sueñas, lo que piensa, este hombre debe ejecutar." Los operadores son más importante que cualquier tecnología en las comunicaciones de éxito en una red. En la mayoría de los casos un nuevo diseño de red es el resultado de obsolescencia o un aumento del orden de la magnitud en requisitos de desempeño. Estos nuevos componentes y herramientas suelen ser radicalmente diferentes a los actualmente en uso por el cliente, y así el personal actual también es probable que sea obsoleto o inadecuado tamaño. Casi siempre es necesario reeducar o reemplazar al personal de operaciones durante el período de transición; también puede ser necesario ampliar radicalmente que el personal si una red de mucha mayor escala es necesaria para satisfacer las crecientes necesidades de comunicaciones. Tenga en cuenta que el reemplazo de los seres humanos en el sistema es mucho más difícil que reemplazar routers switches o fibra multimodo con cable de cobre categoría 6. Estas son las actividades que deben planificarse antes del período de transición e implementación y generalmente tienen un plazo importante, pero debe realizarse antes de que la red alcanza su capacidad operacional inicial (IOC). Es esencial que el ingeniero de red sistemáticamente Descubre necesidades del cliente y las limitaciones en estas áreas, documentarlos y entonces los factores en el diseño. Estos factores tienen una influencia significativa en el grado de automatización que se incorpora en el diseño y el nivel de supuesta habilidad necesaria para hacer funcionar la red. Presentar esta información durante la revisión de diseño ayuda a asegurar que el cliente entiende lo que se necesita para operar la red. También se asegura que cualquier cambio en el diseño (es decir, mayor automatización para compensar un pequeño equipo) se hace temprano en el proceso en lugar de adoquines en el producto final o en un ciclo interminable de órdenes de cambio durante el parto. Uno de los beneficios a un personal de operaciones calificados y motivados es su capacidad de aplicar el arquitectura/diseño de la red básica para resolver nuevas situaciones imprevistas durante la fase de desarrollo. Ausente este conjunto de habilidades, diseño del ingeniero de la red debe ser aún más robusta y un alto grado de automatización para asegurar que el sistema está protegido de los operadores. Puede confiar a improvisar cuando se producen situaciones nuevas, como lo hacen siempre en un conjunto de operadores que respetan los procedimientos documentados y entender la arquitectura del sistema y cómo los componentes trabajan juntos. Un conjunto de operadores no calificados requiere un diseño de sistema que es restricción para asegurar un rendimiento continuo. Un edicto de cliente común es que la nueva red funcionar con el mismo personal como la edad o que, como mínimo, al personal de operaciones no más caro que el actual gabinete. Es esencial que el ingeniero de diseño cumple con el personal de operaciones para desarrollar una opinión sobre su nivel de habilidad y capacidad para entender las nuevas tecnologías y adoptar herramientas y procedimientos nuevos. Hay una relación inversa entre la automatización del sistema y fuerza de trabajo, las ventajas y desventajas que pueden utilizarse los operadores calificados menor. Personal de operaciones de algunos es reacios o incapaces de aprender a operar los nuevos sistemas; nuevo personal debe ser presentada llevar a cabo estas funciones. Requisitos para la selección de operador, la cualificación y la formación (inicial y actualización) pueden parecer onerosos pero son absolutamente necesarios. Si el requisito para conservar el mismo personal es duro y rápido, entonces un diseño del sistema utilizando componentes avanzados y arquitecturas deben tener esto en cuenta.

Requisitos de idoneidad operativa deben ser recogidos de entrevistas con los operadores y propietarios. Si el personal se va a utilizar, entrevistas con personas de aproximadamente el mismo nivel de habilidad deben sustituirse en las entrevistas. Éstos deben ser los operadores, no el diseño equipo de ingeniería, que pueden carecer de la experiencia necesaria para ver cómo el sistema se ve desde la perspectiva del operador. Articular un concepto de operaciones es muy útil para definir las necesidades del cliente, el enfoque general para el equipo de diseño de transporte y garantizar que el cliente ha transmitido completamente su estrategia a los diseñadores. Dicho documento debe ser no más de 10 páginas y debe abordar el nivel de habilidad del operador, la organización del trabajo de cambio, el tempo de las operaciones, el grado en que el operador se espera que vuelva a configurar el sistema, y cómo se hace. Algunas preguntas adicionales a considerar durante el proceso de análisis de requisitos son los siguientes: • ¿Cómo van los operadores para controlar el desempeño para asegurar que detectan fallos,

averías o interrupciones antes de que el cliente no, o ¿los operadores dependen de los usuarios para detectar fallos y reportarlos? • ¿Cómo interactúa el usuario con el sistema y los operadores, incluyendo reportes de problemas, y cómo son estos informes de seguimiento y las respuestas siempre? Si existen varios niveles de calidad de servicio, ¿cómo el usuario final solicitar un aumento o autorizar una reducción en la calidad del servicio? • ¿En qué momento una transición del problema de las operaciones en una acción de mantenimiento, y cómo ocurre esto, por lo que no es descuidado? • ¿Cómo al personal de operaciones monitorear la capacidad del sistema y gestión de alertas a la necesidad de ampliar más allá de los recursos disponibles a ellos? ¿Qué tipos de análisis de tendencias de tiempo promedio será realizada para anticipar el crecimiento de la demanda?

3.8.2 Capacidad de soporte Un componente clave de la satisfacción del cliente con la red de suministro, es su capacidad para mantener el alto nivel de rendimiento alcanzado en el día de la entrega a lo largo de la vida de diseño de la red. Un cliente relativamente sencillo reconocer la mala calidad de un diseño e implementación sólo cuando está con frecuencia fuera de servicio; un cliente bien informado y experimentado examinará el diseño cuidadosamente antes de autorizar la puesta en práctica y querrá saber si persistentemente proporcionará funcionamiento de calidad por su ciclo de vida. Que el cliente también quiere saber lo que se necesita para operar el diseño y lo que se necesita para apoyar operaciones continuas. Un sofisticado cliente comprenderá las implicaciones de un concepto de operaciones y un concepto de apoyo y respetará el compromiso del diseñador de rendimiento después de la implementación es completa y los ingenieros se les paga. Capacidad de soporte es conducido por cinco factores principales: (1) la confiabilidad, mantenibilidad y las características de disponibilidad operacional (RMA) de la arquitectura/diseño; (2) fuerza de trabajo, incluyendo entrenamiento y personal; (3) sistema procedimientos y documentación técnica; (4) herramientas, estándares y especiales; y (5) piezas de repuesto y reparación. Dos clases de mantenimiento que deba realizarse en la red, una vez que se implementa: preventivo y correctivo. Finalmente, los requisitos de mantenimiento se definen como el diseño se solidifica. Requisitos para el mantenimiento, durante esta etapa de la definición de sistema, son generalmente cualitativos en la naturaleza, tales como: • todos los componentes se ubicará donde

se puede mantener en su lugar con un mínimo de interrupción al sistema como un todo. • Se suministra piezas de repuesto para asegurar el reemplazo de cualquier componente cuya falta pondría en funcionamiento de la misión. RMA El primer paso en la definición de requisitos de RMA es articular una muestra representativa de escenarios de misión en la que la red va a ser utilizado. Estos están documentados en una narrativa anecdótica que describe cómo se producirá el uso, cuando se producirá, lo que es necesario que la misión tenga éxito y lo importante que es para los usuarios de la red. Este último elemento incluye con qué frecuencia se utilizará la red y el nivel de prioridad asignado a esta misión. Por ejemplo, la red que se describe en la sección 2.5.3 puede tener usuarios en un solo edificio que requieren acceso a datos en otro edificio que son necesarios para pagar a los empleados; este camino de flujo de datos es necesario solamente de 4 a 17:00 en la tarde del viernes para que nómina puede realizarse localmente el fin de semana y los empleados pago en el lunes por la mañana. Entonces esto se convierte en esencial durante ese período y, como una posición, puede continuar como tal hasta que debe iniciar el tratamiento local o de lo contrario no se conseguirá la nómina el lunes por la mañana, dando por resultado empleados descontentos y todos los desagradable que puede provocar. Este camino ya no es misión crítica el lunes por la tarde y así que podría fallar o ser cerrado para el mantenimiento en ese momento, siempre que no interfiera con otras funciones. Una consideración de diseño posible sería incluir una prueba de sistema automatizado finaldeshilachadas antes del inicio de este período crítico que aconsejaría a los operadores cuando un error del sistema ha producido que, si no corregir, podría retrasar su cheque de pago para la próxima semana . Muchos arquitectónico y características del diseño pueden ser incorporado, pero sólo si el arquitecto/diseñador sabe cómo el sistema va a utilizarse. Basado en los escenarios de la misión, se pueden construir diagramas de bloques de confiabilidad (RBD) para cada misión, que muestra la serie y en paralelas las relaciones entre los componentes y el funcionamiento de la misión. Durante la fase de análisis de requisitos son a un nivel muy alto y reflejan las funciones para lograr la misión, en lugar de componentes para lograr a la misión. Una muestra de RBD se presenta en la figura 3.20.

Figura 3.20 un diagrama de bloques de confiabilidad muestra

Una vez que un diseño está desarrollado y presenta los detalles arquitectónicos, modos de falla y sus efectos deben ser estimados y un análisis de criticidad (FMECA) llevó a cabo para identificar las formas principales en que el sistema puede dejar de cumplir a su misión. Entonces éstos pueden conducir al diseñador a establecer modos de detección que pueda reducir la ocurrencia de fallas o acelerar la restauración del servicio. Una plantilla de datos FMECA se muestra en la figura 3.21. Nombre del

Fecha

componente Nivel de contrato

Número de hoja

Dibujo de

Compilado por

referencia Misión

Artículo / ID

Identificación funcional / Nomenclatura

Aprobado por el

Falta Función

Misión

Falta

Modos Fase o Efecto y

Modo

Causas op

local

Final Efectos

Detección de Modo de

Disposiciones de compensación

Clase de severidad

Observaciones

Figura 3.21 una plantilla para los datos FMECA

En la realización de la RMA análisis del diseño es esencial recordar que el RMA es una herramienta para el diseñador de entender el rendimiento del sistema para que él o ella pueda hacer decisiones informaron. Mano de obra Como de aptitud operativa, las discusiones de soporte se centran a menudo en retener la fuerza de trabajo o mantener el presupuesto de la misma. Con la introducción de tecnologías nuevas y sofisticadas, esto puede presentar problemas. Reconversión de mano de obra o sustitución se requiera en la ejecución. Otro enfoque consiste en equilibrar las actividades de mantenimiento mediante el uso de servicios expertos en aquellas áreas donde la fuerza de trabajo carece de las habilidades. En algunos casos puede tener sentido externalizar el mantenimiento, particularmente en situaciones donde la red es una función de soporte de la línea principal del dueño del negocio y no hay ningún interés en el desarrollo de una plantilla altamente especializada, cara, interna . Durante la fase de análisis de requisitos el objetivo principal es obtener un panorama claro de las restricciones del cliente en el cambio de la fuerza de trabajo. El personal que operará y mantener la red necesita ser correctamente entrenados y debidamente cualificados. Una aproximación a la definición de requerimientos en esta área es inspeccionar la habilidades existentes de mano de obra, la profundidad y la formación, documentar estas características y usarlas como base para el nuevo personal de mantenimiento de red. Cualquier cambio necesario entonces pueden tratarse como los cambios de ingeniería a las exigencias de la línea de base y la fuerza de trabajo. Procedimientos y documentación En general, tres clases de documentación están necesario para la red. Sistema y componente de la documentación técnica describe las características, partes y como el conjunto completo de equipos que conforman el diseño. Procedimientos de mantenimiento describen las acciones de mantenimiento preventivo periódicos necesarias para mantener el sistema funcionando correctamente y su actuación programada. Accidentes procedimientos describen el anormal (esperemos) procedimientos a seguir cuando se producen fallos de sistema. Estos están diseñados para minimizar el daño al sistema y en restaurar el servicio lo antes posible; una planificación previa para espera los modos de falla va a hacer más para restaurar el servicio rápidamente que cualquier otra inversión durante la implementación.

Documentación técnica es generalmente proporcionado por el proveedor de los componentes y es generalmente suficiente. Durante la implementación, la documentación debe ser inspeccionada para asegurar ese repuesto y piezas de repuesto se identifican por lo que si necesitan ordenarse rápidamente en respuesta a una falla o falta, la lista de piezas está disponible. Documentación técnica para describir la integración de componentes de red es generalmente nuevo material que el equipo de ingenieros debe generar como parte de la prueba, implementación e integración de la nueva red. Procedimientos de mantenimiento deben apoyar ambos mantenimiento nivel de componente y sistema. La documentación debe identificar la frecuencia y procedimientos para efectuar mantenimiento preventivo así como los procedimientos para volver a configurar la red para operar temporalmente en una capacidad reducida mientras que componentes de reemplazo se intercambian hacia fuera para revisión y mantenimiento. Tales procedimientos identifican las herramientas y las condiciones iniciales necesarias para iniciar el procedimiento, las pruebas deberán ser hechas antes de devolver el sistema a un estado normal y los indicadores que el mantenimiento se ha realizado correctamente o incorrectamente. Accidentes procedimientos describen las acciones previstas para los operadores a realizar cuando se produce una falla en el sistema. Estos se dividen en acciones inmediatas y acciones adicionales. Están diseñadas para colocar el sistema en un estado seguro y para funcionar a capacidad reducida hasta que la falla puede ser aislada y reparada con servicio completo restaurada. Durante la fase de análisis de requisitos, el alcance de cada una de estas clases de documentación debería documentarse como un conjunto básico de requisitos. Herramientas El aprovisionamiento de herramientas y equipos de prueba especiales y comunes es una consecuencia de la arquitectura de red y el diseño. En esta etapa los requisitos en este ámbito representan posibles limitaciones en la arquitectura y el diseño. Debe ser indicados en términos de crecimiento sobre el conjunto de herramientas actualmente poseídos por el personal de mantenimiento existente. Junto con los componentes que sean necesarios al servicio, en lugar de por separado, para asegurar que funcionen correctamente con la configuración de la red planificada, se deben adquirir nuevas herramientas. Equipo de prueba especial, monitoreo y software de diagnóstico requisitos deben definirse durante esta fase en términos de su capacidad para mejorar el tiempo de respuesta a problemas de rendimiento del sistema, incluyendo fallas y defectos. Esto puede representar un esfuerzo de desarrollo o, como mínimo, un esfuerzo de integración como la red es desplegado. Sería razonable en este punto especificar una capacidad para detectar fallos del sistema y la degradación de rendimiento y para mostrar el estado y parámetros en la consola del operador, o mediante un navegador Web desde un servidor central. Otro requisito para la consideración es la capacidad para supervisar, configurar, o restablecer los componentes de enrutamiento usando conexiones fuera de banda, como una línea analógica y un módem atado en un puerto de mantenimiento de los dispositivos de enrutamiento de red. Esto repercute en que los dispositivos cumplan estos requisitos, y para una red con componentes en una distancia de los operadores, podrá permitir el mantenimiento sin visitas físicas. Reparación y repuestos

Requisitos para imponerse en el inventario de piezas de repuesto y reparación en esta etapa son las restricciones cualitativas, no una lista de artículos que se entregarán. Algunos requisitos de la muestra que los clientes pueden definir en este punto las siguientes: • Repuesto y reparación de las piezas se almacenarán en el centro de operaciones de red y no

puede exceder, en volumen, el espacio asignado, que es n pies cúbicos. • Piezas de repuesto y reparación iniciales no excederá el 15% de los costos de adquisición del

sistema. • Contratar vehículos de repuesto de reemplazo y reparación de piezas será antes de la capacidad

operativa inicial. Requisitos específicos para el mantenimiento son conducidos generalmente por el diseño y la arquitectura de red y están documentados en un plan de mantenimiento basado en el diseño. Finalmente, las piezas de repuesto y reparación provisioning se deriva el diseño actual y un análisis del mantenimiento del diseño. Concepto de apoyo El concepto de apoyo describe la forma en que se apoya la red. Definir el concepto claramente puede ayudar a articular las limitaciones del cliente y ayuda a identificar alternativas para apoyar a que pueden ser acomodados en el diseño. Un concepto de apoyo de mantenimiento comúnmente aceptado es el modelo de tres niveles. A nivel local, los operadores pueden realizar un conjunto de acciones de mantenimiento mínimo. Que monitor de falla de un componente y aislar el problema. Puesto que son a menudo en el sitio, o al menos cerca de los componentes, que pueden manejar acciones inmediatas para fallas de sistema o bajas y algunas acciones adicionales, tales como desvío de circuitos o reemplazar algunas unidades reemplazables en línea. El segundo nivel es el mantenimiento de nivel intermedio, que incluye la capacidad de reparar algunos de los componentes o proveer un lugar para la reparación in situ por los representantes de servicio de fábrica, si están trabajando localmente. Este nivel implica la dotación de personal con conocimientos especializados y un conjunto limitado de equipos. Con frecuencia esto se maneja a través de contratos de servicio con el proveedor o un tercero quien está suficientemente como para poder llegar en el sitio en un período corto de tiempo. El tercer nivel es el servicio de fábrica que generalmente implica un contrato por servicio y envío el equipo a una ubicación de mantenimiento para su reforma o reparación. Nivel

Ubicación

Herramientas y

Mantenimiento

equipos de prueba

correctivo

Sitios de las

Operadores

operaciones

de

• Herramientas comunes

• Seguimiento día a día

• Controles y consolas

• Solución de problemas

de operador

Organizacional • Baratos herramientas especiales

• Aislamiento de fallas • Sustitución de remotas • Reconfiguración del sistema

El llamado a

Con personal

Especiales o costosas

Reparación in situ de

trabajar en el

capacitado

herramientas portátiles

offline

sitio

que

con uso limitado

equipo

Intermediar en

Mantenimiento

Quién preventivo • Vigilancia del desempeño de • Menor limpieza in situ y ajustes • Reemplazo programado de remotas • Actualizaciones in situ mayores donde es

función

impráctico el envío a

primordial es

fábrica

el

• Operadores de

mantenimiento

suplemento

Personal del

Equipo para la

proveedor o

renovación de

fábrica

componentes

Proveedor o Depot

Revisión programada o el Revisión y renovación

fábrica

desmontaje de remotas

Figura 3.22 la estructura de tres niveles de mantenimiento

En el enfoque de tres niveles (Figura 3.22) los operadores locales simplemente identifican el componente fallido, tirón de la Unidad reemplazable de línea que la contiene y reemplazarlo para restaurar el servicio. La unidad de reparación local fallada (LRU) luego viene el segundo nivel o incluso a la fábrica para su reparación o reacondicionamiento. Documentación debe ser proporcionada a la fuerza de trabajo de nivel 1 que describen cómo tirar y reemplazar los componentes, y deben tener un conjunto limitado de herramientas y equipos especiales para llevar a cabo estas funciones. El grado a que se utilizan los servicios contratados se debe abordar también el concepto de apoyo. Generalmente, en esta etapa del análisis de requisitos, es suficiente documentar el modelo actual de soporte e identificar los cambios que están probable que sean necesarios para soportar la nueva red.

3.8.3 Confianza La confianza es una medida de la capacidad de la red para ofrecer los datos sin errores o pérdida en el rendimiento requerido. Esto puede estimarse en términos de tasa de error o pérdida. Mientras que las tasas de error, pérdida se utilizan más comúnmente en los dispositivos de red, también podemos derivar algunas estimaciones del rendimiento de ellos. Como con otras estimaciones de rendimiento, la capacidad de estimar el tiempo de actividad se basa fuertemente en nuestra capacidad para medir en el sistema. Para estas tarifas, esto se hace • Por enlace o circuito, tales como poco error precios (Bras) • Tasas de pérdida de paquetes entre routers de capa de red • End-to-end, entre dispositivos o aplicaciones de computación

Determinar lo que es una tasa aceptable de errores o pérdida depende de la capacidad de la aplicación para tolerar errores o pérdida de la información. Esto, a su vez, implica fiabilidad y las dependencias entre las distintas capas de la red. Por ejemplo, una aplicación que transfiere datos en la red puede depender de la capa de transporte para proveer transmisión garantizada. Si la capa de transporte utilizada es el protocolo de control de transmisión (TCP), fiabilidad de la transmisión se basa en capacidad de TCP para recuperarse de errores en la red o sobre la notificación de errores de transmisión. Si el protocolo es el protocolo de datagramas de usuario (UDP), sin embargo, allí no es ninguna garantía de fiabilidad de la capa de transporte y fiabilidad se transmite a las capas físicas y enlace de datos o debe ser proporcionado por la propia aplicación. Pérdida a menudo se mide en el físico, enlace y red capas y reportados como un porcentaje del tráfico disponible en la red. Así, podríamos establecer los umbrales de pérdida celular, marco o paquete y periodos de tiempo, como se muestra en la figura 3.23.

Curiosamente, podríamos utilizar la utilidad ping de conocidos como una herramienta de medición posibles. Una tasa de pérdida de ping puede utilizarse como un indicador de que la red se aproxima a un umbral de pérdida y que una medición más precisa (por ejemplo, SNMP remoto o interrogación de las estadísticas del router monitoreo variables [RMON]) es necesario. Mientras que el ping puede ser útil en este modo, la pérdida de paquetes ICMP (ping se compone de dos partes, ICMPEcho de solicitud y respuesta) puede verse afectada por cómo manejan dispositivos de red (como routers). Por ejemplo, paquetes de ping pueden ser entre los primeros paquetes a descartarse selectivamente por un router cuando se congestiona. El punto importante aquí es utilizar utilidades como ping con una conciencia que (como todas las aplicaciones) es imperfecto y no puede representar siempre con exactitud el estado del sistema. Por esta razón puede ser mejor utilizado como un indicador de umbral, provocando otro método de medición cuando se cruza el umbral, que tendría menos de un impacto directo en las mediciones de precisión y pérdida, mientras que todavía siendo bastante útil. Hay algunas aplicaciones que se van a tolerar cierta pérdida de información. Aplicaciones que la transferencia de video o voz, tales como teleconferencia o telelearning, Tasa de pérdida de paquetes (% de tráfico de la red Total)

Tiempo Total máximo (por semana)

2% o mayor

Hasta 1 minuto

Menos del 2%

Resto de la semana

Figura 3.23 un umbral de pérdida de ejemplo

Límites y umbrales específicos de medio ambiente

permitirá algún tipo de pérdida para preservar la continuidad del tiempo de la sesión. Algunas aplicaciones de misión crítica de la telemetría permiten también pérdida de datos.

3.9 Límites y umbrales específicos de medio ambiente Límites y umbrales generales nos dan algunas estimaciones comunes para requerimientos de bajo y alto rendimiento para nuestra red. Son útiles cuando hay una falta de información sobre los usuarios, aplicaciones y dispositivos de la red, pero a menudo hay información sobre lo que los umbrales de rendimiento debe ser. Con esta información podemos desarrollar umbrales y límites específicos de esa red. Límites y umbrales específicos de medio ambiente son un reconocimiento que cada red es única, y que los requerimientos de los usuarios, aplicaciones y dispositivos son específicos para el medio ambiente que son. El ambiente toma en conceptos de la cuenta como el tipo de trabajo que hacen los usuarios, o cuáles son sus objetivos (por ejemplo, qué les motiva). Así, un ambiente de investigación académica es muy diferente desde un retail (ventas), que es diferente de un entorno

de fabricación y así sucesivamente. Los umbrales que distinguen entre bajo y alto rendimiento son exclusivos para cada ambiente. Dado que cada entorno es único, lo que puede considerarse para un entorno de alto rendimiento puede ser bajo rendimiento por otra. Reconocer la singularidad de cada entorno (y por lo tanto, red) trabaja en es un buen hábito a desarrollar, especialmente si usted está implicado con muchas redes diferentes. Como los umbrales de la general, la razón para desarrollar umbrales específicos de medio ambiente es determinar qué aplicaciones tienen requerimientos de alta performance. Hemos dedicado mucho tiempo a esto; ¿por qué es tan importante? Para cada proyecto de la red que trabajamos, tenemos que: 1. Determinar si hay cualquier dispositivos y aplicaciones de alto rendimiento y si es así, ¿qué tan importantes son para el éxito de ese entorno? ¿Lo importante es que se apoya? Si no hay ninguna aplicaciones de alto rendimiento (múltiples niveles), entonces la red apoyará un conjunto de dispositivos y aplicaciones de rendimiento de la solo-grada. 2. Si hay alta (varios niveles)-aplicaciones y dispositivos y son cruciales para el éxito de ese entorno, entonces es probable que nuestro diseño y arquitectura de red se centrarán en el apoyo a las aplicaciones y dispositivos, así como sus usuarios. Por lo tanto, nuestra capacidad para determinar qué usuarios, aplicaciones y dispositivos son importantes para el éxito de la organización que la red de apoyo y determinar si las aplicaciones y dispositivos son relativamente alto rendimiento para el ambiente, o más o menos lo mismo que todas las otras aplicaciones y dispositivos, afectará el éxito de la arquitectura de red resultante y el diseño.

3.9.1 Comparación de requisitos de aplicación Desarrollo de límites y umbrales específicos de medio ambiente se basa en comparar los distintos requisitos de rendimiento de aplicaciones. Normalmente, se trazan una, dos o todas las características de funcionamiento (capacidad de demora y RMA) para las aplicaciones, y la trama se utiliza para comparar requisitos de desempeño relativo y desarrollar un umbral o límite para esa característica. Por ejemplo, considere un diagrama de requisitos de capacidad para aplicaciones en una red. Estos pueden ser un subconjunto de todas las aplicaciones para el ambiente, como la parte superior cinco o seis en orden de importancia o de rendimiento. Figura 3.24 se muestra la trama resultante. Hay un grupo de aplicaciones en el rango de capacidad 50Kb/s, alrededor de 1Mb/s y luego aplicaciones en alrededor de 4Mb/s y 6,5 Mb/s. Podríamos elegir las mejores aplicaciones de uno o dos y poner un límite entre ellos y el resto de las aplicaciones. Probablemente, los dos primeros se agrupan y un umbral había situado alrededor de 2 a 3Mb/s. Como se puede ver en la figura 3.24, los requerimientos de capacidad de las aplicaciones se distribuyen en un rango de valores. Podríamos elegir desarrollar un límite de rendimiento (environmentspecific) para este grupo de aplicaciones, o un umbral entre bajo y alto rendimiento, o ambos. Tenga en cuenta que, por retraso, un límite superior para el alto rendimiento es realmente el valor más bajo retardo, no el valor más alto.

Figura 3.24 una parcela de requerimientos de capacidad con posibles umbrales

Requisitos para el funcionamiento previsible y garantizado

Figura 3.25 una parcela de requerimientos de capacidad con No distintas agrupaciones

En esta figura, podríamos estimar un par de los umbrales de capacidad posible. Lo más probable sería agrupar aplicaciones de C y F y colocación de un umbral de alrededor de 2 a 3Mb/s. Este valor es subjetivo y puede necesitar ser aprobado por la administración o los usuarios. A veces el umbral o límite es evidente; en otras ocasiones puede ser difícil de determinar. Consideremos, por ejemplo, la siguiente trama de capacidades de aplicación (Figura 3.25). En esta figura, los requerimientos de capacidad también se extienden en un rango de valores, pero en este caso no hay ninguna separación clara entre bajo y alto rendimiento. Cuando los requisitos de rendimiento no están claramente separados, no pueden ser capaces de desarrollar un umbral.

3.10 Requisitos para la predecible y Rendimiento garantizado Junto con la determinación de límites, umbrales y requisitos de desempeño, también hay que considerar si existen requisitos para desempeño predecible o garantizada. Usted recordará del capítulo 1 que servicio predecible (cuyo rendimiento es una parte) requiere previsibilidad y fiabilidad — más de lo posible, mientras que servicio garantizado tiene responsabilidad como parte de su especificación. Los requisitos de rendimiento para ambos de estos tipos de servicio son más estrictos que el servicio estándar de mejor esfuerzo. Así, cuando se especifica el rendimiento previsible y garantizado por una red, desea estar seguro de que el cliente realmente necesita o quiere y es consciente de los costos (financiero, personal, intelectual y posiblemente horario) para implementar y mantener.

3.10.1 Requisitos de Performance predecible Varios de los ejemplos discutidos en este capítulo pueden considerarse predecibles. Dependiendo de cuán importante son los usuarios y aplicaciones para el éxito de una organización, sus requerimientos pueden ser predecible, que requieren más apoyo para sus flujos de tráfico necesario. Esto significa que, en la arquitectura de red y el diseño, sus flujos se tratan diferentemente de mejor esfuerzo. Que se hará es cubierto más adelante, pero por ahora es suficiente para poder identificar y especificar esos requisitos de performance predecible. Ha habido varios indicadores de performance predecible lo que va de este libro. Hemos hablado de aplicaciones de misión crítica, velocidad crítica, en tiempo real e interactivas. Estos términos indican capacidad predecible o garantizada, retardo y RMA, respectivamente. También hemos hablado de desarrollo generales y específicas del entorno umbrales y límites para separar bajo y de alto rendimiento para redes de varios niveles de rendimiento. Las aplicaciones que se caracterizan por ser de alto rendimiento son también candidatos para servicio predecible. De

hecho, el umbral entre bajo y alto rendimiento a menudo puede ser el umbral entre el servicio de mejor esfuerzo y predecible. Por lo tanto, si especifica requisitos de funcionamiento como previsible se basa en

• Determinar si la aplicación es esencial, velocidad crítica, en tiempo real o interactivo • Determinar si hay límites o umbrales de performance específicas del entorno • Aplicación general umbrales y límites, si es necesario • Discutiendo los resultados con sus clientes (usuarios, administración, etc.) de acuerdo en que

deben tenerse en cuenta requisitos predecibles

3.10.2 Requisitos para rendimiento garantizado Garantizar requisitos de rendimiento son los más estrictos requisitos de la red, no necesariamente en cuanto al nivel de rendimiento sino más bien en términos de lo que se necesita para apoyar (o garantizar) rendimiento al dispositivo, aplicación o usuario. Como con requisitos previsibles, requisitos de garantía se indican cuando se identifican aplicaciones de misión crítica, velocidad crítica, en tiempo real o interactivos, así como cuando se identifican los requisitos del alto rendimiento (múltiples niveles). Requisitos de asignación de

Lo que hace que un requisito de desempeño garantizado es el grado al que ese requisito debe apoyarse en la red. Soporte para los requisitos de garantía tiene que tener responsabilidad en él. Esto significa lo siguiente: • Tiene que haber algún tipo de acuerdo, generalmente entre los usuarios de la aplicación y los

proveedores del servicio de red que soporta la aplicación, sobre 1. Los requisitos de rendimiento son 2. Cuando y donde se aplican 3. Cómo será medidos y verificados 4. Qué sucede cuando un requisito no se cumple Este acuerdo puede ser en forma de un acuerdo de nivel de servicio (SLA), utilizada por los proveedores de servicios. • Los requisitos deben considerarse extremo a extremo entre origen y destino. Más sobre esto

puede encontrarse en el capítulo de análisis de flujo (capítulo 4). Los factores utilizados para determinar los requisitos de rendimiento garantizado son los mismos en cuanto a requisitos de desempeño predecible, con especial énfasis en el último factor

(discutiendo los resultados con su customer(s)). Llegar a un acuerdo de su cliente en que el desempeño requisitos deban garantizarse es especialmente importante, como el impacto sobre los recursos puede ser sustancial. Como vamos a ver, cómo especifica requisitos aquí puede tener un grave impacto en la arquitectura de red y el diseño a seguir. Por lo tanto, el esfuerzo más pone en esto, mejor serán el resultante de la arquitectura y el diseño.

3.11 Requisitos de asignación de Otra parte del proceso de análisis de requisitos es mapeo de requerimientos. En el capítulo 2 discutimos la importancia de determinar la ubicación de importantes dispositivos y aplicaciones. Como parte del proceso de análisis que reunirá esa información de ubicación en un mapa de donde los dispositivos son (o parecen ser) y aplicaciones aplicaran (o están probables que aplique). Requisitos se asignan a una descripción geográfica del medio ambiente. Esto puede ser un edificio o campus, pero también puede ser abstraído opiniones metropolitana o de área amplia. De hecho, puede haber varias vistas del entorno, cada uno enfocándose en un área geográfica particular. Por ejemplo, un mapa puede ser una vista amplia, mostrando las ciudades donde se aplican los dispositivos y aplicaciones. Cada ciudad puede tener entonces su propio plano, el campus y edificios (Figura 3.26). Figura 3.27 se muestra un ejemplo de un mapa de necesidades. En este mapa de un campus se colocan las ubicaciones de los dispositivos (servidores y dispositivos especializados) y aplicaciones. De este mapa podemos comenzar a correlacionar las partes del campus va a utilizar que aplicaciones y dispositivos, y podemos calcular donde podrían ocurrir flujos de tráfico, dentro de una aplicación, entre aplicaciones y entre los dispositivos. Tenga en cuenta que en este mapa, los grupos de dispositivos informáticos genéricos también aparecen. Mostrar escritorio individual o dispositivos portátiles no es práctico y no es probable que proporcionar información importante. Sin embargo, Mostrar grupos, da una indicación de Cuántos dispositivos y los usuarios son en un lugar en particular. Esto es útil en el proceso de análisis de flujo. El caso degenerado de un mapa de necesidades es uno donde todas las aplicaciones aplican en todas partes, y no hay servidores o dispositivos especializados para mostrar. Hay poca, o ninguna, información que puede ser determinado por tal mapa.

Figura 3.26 requisitos múltiples mapas

Desarrollo de la especificación de requisitos

Figura 3.27 Campus requisitos mapa

3.12 Desarrollo de la especificación de requisitos La especificación de requisitos y requisitos mapa son los resultados del proceso de análisis. La primera parte del proceso es determinar las condiciones iniciales para el proyecto. Esto incluye el tipo de proyecto de red, alcance del proyecto, objetivos del proyecto y fuerzas políticas, administrativas y financieras del proyecto. Parte de las condiciones iniciales del proyecto se puede determinar si la red necesita solo nivel o varios nivel de rendimiento. Nos también hacer una

evaluación inicial rápida de los problemas en la red, si alguna y estimación de recursos y calendario. Por lo tanto, antes de que nos hemos reunido todos los requisitos para la red, debemos tener algunos o todos de esta información documentada. Considere el ejemplo de una red de edificio del capítulo 2. La primera parte de la especificación de requisitos puede verse como la figura 3.28. La segunda parte de la especificación de requerimientos comprende los requisitos reunidos y derivados de la red. En este ejemplo fueron algunos requisitos Especificación de requisitos Sección 1: Condiciones iniciales Proyecto

Actualización de red

Tipo Proyecto Ámbito de

Solo edificio, dos pisos, aproximadamente 150 usuarios

aplicación Proyecto

Mejorar el rendimiento para todos los usuarios, particularmente algunas aplicaciones de misión

Objetivos

crítica e incrementar la seguridad en Internet

Otros Condiciones

Financiera TBD

Definición y evaluación del problema

Rendimiento de la aplicación ha sido un problema recurrente, gestión quiere actualizar la red y ha sugerido actualizar interfaces Fast Ethernet. Algunos usuarios tienen interfaces GigE en sus estaciones de trabajo.

Figura 3.28 una plantilla para las condiciones iniciales

aprendido en nuestra discusión inicial con el cliente (dirección y personal). Estos requisitos se muestran en la figura 3.29, con la plantilla del capítulo 2. No siempre es el caso que requisitos se pueden obtener de las primeras reuniones. Para obtener los requisitos de los usuarios, suelen hacerles preguntas sobre su

Especificación de requisitos

Sección 2: Lista de los requerimientos ID /

Se reunieron / Fecha

Tipo

Descripción

Nombre

Lugares

Estado

Prioridad

derivados Distribución de usuario es: 60 14 01

1

ingenieros, 15 HR y finanzas,

Reunidos desde

fabricación, gestión de 10, 30

la administración

Usuario de ene

TBD

Información

TBD

TBD

TBD

TBD

TBD

TBD

TBD

Marketing y ventas, 5 de 30 otros Debe apoyar cada área del edificio 14 01 2

Reunidos desde Red

Conexiones rápidas de Ethernet a la

de ene

la administración red troncal Aplicaciones de base de datos,

14 01 3

Reunidos desde Aplicación

visualización, fabricación y nómina

de ene

la administración se consideran críticos para esta

empresa. Más información necesaria.

Aplicación de nómina (PAY1) 14 01 4

requiere 100% uptime (mientras está

Reunidos desde

en funcionamiento) entre finanzas y

la administración

Aplicación de ene

TBD

TBD

TBD

TBD

TBD

TBD

nómina fuera empresa 14 01 5

Compañía debe estar segura de

Reunidos desde

Ataques de Internet

la administración

Red de ene

Requisitos de la figura 3.29 se reunieron desde la reunión inicial con el cliente

Desarrollo de la especificación de requisitos

1. aplicaciones lista que utilizas

¿Con qué

¿Por cuánto

frecuencia? (veces

tiempo cada

al día)

vez?

Interfaz de red

Sistema operativo

Aplicación 1Aplicación 2Aplicación 3Aplicación 4Aplicación 52. lista de equipos u otros dispositivos que utilizan conectados a red Dispositivo 1 (escritorio o portátil)Dispositivo 23. ¿ha tenido algún problema con la red? Si es así, por favor, dar una breve descripción de cada problema Problemas-

4. Qué capacidades gustaría ver en la red (desempeño, características) RendimientoCaracterísticasOtros5. ¿tienes algún problema o problemas con la seguridad? Si es así, por favor, dar una breve descripción de cada problema. Problemas de seguridad-

¿6. cualquier otras sugerencias, problemas o comentarios? Sugerencias / Temas /

Comentarios

Figura 3.30 una plantilla para el cuestionario de

medio ambiente. Para este ejemplo, un cuestionario fue desarrollado y enviado a todos los empleados de la empresa. Figura 3.30 muestra tal cuestionario. Por supuesto, no todo el mundo a responder al cuestionario. La experiencia ha demostrado que en cualquier lugar de 10% a 40% responderá. Esto depende de cuánto tiempo el cuestionario es lo difícil que es llenar y cómo es grande es la organización. También, tiende a obtener la mayoría de las respuestas en unos pocos días, pero algunos por goteo Especificación de requisitos

Parte 2: Listado de requisitos ID /

Se reunieron / Fecha

Tipo

Descripción

Nombre Inventario de aplicación (INV1) 6

Lugares

Estado

Prioridad

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

TBD

derivados

20Jan01

Aplicación

para la fabricación de requisitos no determinados en este momento

Recogidos de los usuarios (hombre) Recogidos de

Dispositivo 7

Los usuarios de ingeniería tienen

25Jan01

los usuarios de

estaciones de trabajo con NIC GigE (ENG) Otras aplicaciones generales:

02 01 de 8

correo, procesamiento de textos,

Obtenida de la

Aplicación Feb

acceso a la Web interna y

red personal

externa. Más información necesaria

Figura 3.31 requisitos adicionales de la encuesta

durante un largo periodo de tiempo (por ejemplo, unas pocas semanas). Puede actualizar los requisitos de un par de veces basados en los resultados de nuevas respuestas. Los resultados del cuestionario de ejemplo se muestran en la figuras 3.31 y 3.32. Estos requisitos fueron refinados y agregar al encuentro con cada uno de los grupos (incluyendo reuniones con la gerencia y el personal de la red) en la empresa.

Especificación de requisitos

Parte 2: Listado de requisitos

ID / Nombre

Se Fecha

Tipo

Descripción

reunieron /

Lugares

Estado

Prioridad

derivados Aplicación de base de datos (DB1) 9

01Feb01

Aplicación

requiere un mínimo de 150 Kb/s por

Reunió de TBD

TBD

TBD

TBD

TBD

TBD

N/A

Información

TBD

TBD

TBD

TBD

varios usuarios sesión 02 01 de 10

Empresa requiere un mínimo de T1

Obtenida de la

acceso a Internet

red personal

Red Feb

Red actual completamente 02 01 de 11

Obtenida de la Red

reemplazará, por lo que hay no hay

Feb

red personal requisitos de red existente Aplicación de visualización (VIS1) de finanzas requiere hasta

12

05Feb01

Aplicación

40 Capacidad de mb/s y 100 ms

Derivados de la aplicación

retardo de ida y vuelta

Figura 3.32 requisitos adicionales de reuniones con los usuarios y el personal

Ejercicios

3.13 Conclusiones El proceso de análisis de requerimientos le proporciona los medios para el análisis de la red y el medio ambiente que lo contiene. Aprendieron sobre recolección y manejo de usuario, aplicación, dispositivo y requisitos de la red. Esto incluye la determinación de las condiciones iniciales para el proyecto y configuración y administración de sus expectativas de clientes de la red. Condiciones iniciales varían, dependiendo de la red, el sistema y el medio ambiente, así como si la red es nueva o una actualización de un existente de la red. Armado con las condiciones iniciales, puede reunir los requisitos de los usuarios, administración y gestión y asignar requisitos de aplicación para determinar sus dependencias. Usted aprendió acerca de cómo determinar las variables a medir (métricas de servicio) y cómo hacer las mediciones. Sus opciones de métricas de servicio conducirá a definir variables para gestión y monitorización de la red. Hablamos de modelado y simulación, y cómo ellos y otras técnicas de aproximación pueden utilizarse para describir el comportamiento de usuario y aplicación. Basándose en las métricas de servicio, nos enteramos en desarrollo requisitos de funcionamiento para capacidad de demora y RMA, con desarrollo de umbrales de rendimiento y límites. Estos son útiles en la distinción entre alto rendimiento y bajo los requisitos de la red. También hemos aprendido sobre umbrales generales y específicas de medio ambiente y límites y cómo determinarlas. Algunos umbrales generales se presentan para su uso. También hablamos de requisitos de rendimiento garantizado y predecible y su importancia. Por último, hablamos de requisitos de asignación de ubicaciones geográficas, en preparación para el análisis de flujo de tráfico. En el siguiente capítulo, os traemos todos estos conceptos para desarrollar una especificación de requisitos de la red.

3.14 Ejercicios 1. Condiciones de inicial para su proyecto de red consisten en las siguientes categorías: tipo de proyecto de red, el alcance del proyecto de red y los objetivos de diseño de la arquitectura. Desarrollar tres conjuntos de condiciones iniciales (cada uno que contiene un elemento de cada categoría) y dar un proyecto de red de ejemplo para cada conjunto. 2. Para cada conjunto de requisitos de rendimiento de la aplicación se muestra en la figura 3.33, clasificar la red como el rendimiento de la solo-grada o multinivel. Requisitos de desempeño Conjunto de aplicaciones Capacidad

Fiabilidad

Retardo de

Aplicación 1

150 Kb/s

N/A

N/A

Aplicación 2

200 Kb/s

N/A

N/A

Aplicación 3

90 Kb/s

N/A

N/A

Aplicación 4

120 Kb/s

N/A

N/A

Aplicación 1

75 Kb/s

99.999%

N/A

Aplicación 2

150 Kb/s

N/A

N/A

Aplicación 3

250 Kb/s

99.999%

N/A

Aplicación 4

200 Kb/s

N/A

N/A

Aplicación 1

1.1 Mb/s

99.95%

40 ms

Aplicación 2

800 Kb/s

N/A

N/A

Aplicación 3

950 Kb/s

N/A

100 ms

Aplicación 4

120 Kb/s

N/A

N/A

Aplicación Set 1:

Aplicación sistema 2:

Aplicación Set 3:

Figura 3.33 requisitos de rendimiento de aplicación para el ejercicio 2

3. Su cliente es un hospital que quiere actualizar su LAN. Desarrollar un cuestionario para reunir los requisitos de los usuarios, gestión hospitalaria y personal. ¿Qué tipo de preguntas le preguntarías a entender mejor su entorno? 4. Considere un proyecto de red donde usted no puede hablar con los usuarios o personal. ¿Qué recursos puede utilizar para recopilar usuarios, aplicación, dispositivo y requisitos de red? Describir brevemente un método para la recolección y derivar los requisitos en la ausencia de participación del usuario y el personal. 5. Quiere probar el funcionamiento de sesiones Web en una red de acceso inalámbrica entre PC y un router IP que termina Protocolo punto a punto (PPP) y PPP sobre sesiones de Ethernet (PPPoE), como se muestra en la figura 3.34. Describir cómo sería probar rendimiento, en un banco de pruebas y en la red. Lista de cualquier equipo, software y dispositivos de red utilizaría.

Ejercicios

Figura 3.34 conexiones inalámbricas a la red corporativa usando PPP y PPPoE

6. Mostrar cómo los siguientes cambios en el requisito abajo orugas/gestionar. Utilizar el párrafo o forma tabular a los cambios de registro. Requisito: 12 de octubre de 2002. Red debe ser capaz de soportar hasta 2000 interfaces Fast Ethernet, agregadas a 1Gb/s o columna vertebral de capacidad mayor que abarca todos los 12 edificios en el campus. a. Cambio "Fast Ethernet" a "Fast Ethernet o Gigabit Ethernet," fecha 05 de enero de 2003. b. Eliminar "12 edificios en el campus," fechadas 07 de enero de 2003. c. Cambio "2000" a "3500", de fecha 10 de febrero de 2003. d. Añadir "10 edificios enumerados en el Apéndice A," de fecha 20 de enero de 2003. e. Cambio "Fast Ethernet" a "Fast Ethernet o Gigabit Ethernet" "10, 100 o 1000Mb/s," fecha 05 de marzo de 2003. f. Cambio de "agregados" a "agregada en cada edificio," de fecha 21 de abril de 2003. 7. Métricas de servicio de se utilizan para monitorear, medir y verificar los servicios en la red y determinar si se cumplen requisitos de desempeño. Por lo tanto, métricas de servicio deben ser significativos a los operadores de red, administradores, usuarios y personal. Para cada requisito de desempeño a continuación, describir una métrica de servicio que podría utilizarse para medir y verificar el requisito de. a. Confiabilidad de un enlace T1 entre una red empresarial y su ISP, con enrutadores de IP en cada extremo de la T1. b. Retardo de ida y vuelta entre dispositivos de red A y servidores en servidor LAN B. c. Tasa de tráfico medio dentro y fuera de un servidor de cálculo, medido a través de los cuatro de sus interfaces de LAN en intervalos de 15 minutos. 8. Requisito de MTBCF un dado de 8000 horas y un tiempo medio de reparación de 4 horas, calcular un requerimiento de disponibilidad. 9. Describe dos maneras de hacer un requisito de tiempo de actividad del 99,999% más precisos. 10. Está desarrollando una red de la FAA para una telemetría tramitación de solicitud que consta de dos componentes: un sistema automatizado de control de dirección que se analiza datos de la telemetría de los aeroplanos y un sistema de visualización de movimiento utilizado por controladores en sus estaciones de trabajo (Figura 3.35). En el análisis de esta aplicación han determinado que la aplicación requiere un máximo retardo unidireccional de

Figura 3.35 un diagrama del sistema de ejercicio 10

20ms entre un avión y el sistema de dirección-control. Además, los controladores interactúan con aviones a través del sistema de visualización de movimiento con demoras del orden de terapia de reemplazo hormonal. Desarrollar límites superior e inferior de la demora para esta aplicación y mostrar en un gráfico.

Esta página dejada intencionadamente en blanco

CAPÍTULO CONTENIDO 4.1 Objectives

4.1.1 Preparation 4.2 Fondo 4.3 Flujos de 4.3.1 Flujos individuales y compuestos 4.3.2 Corrientes críticas 4.4 Identificación y desarrollo de flujos de 4.4.1 Centrarse en una aplicación Particular 4.4.2 Desarrollo de un perfil 4.4.3 Elegir el NApplications superior 4.5 Datos fuentes y fregaderos 4.6 Modelos de flujo 4.6.1 Peer-to-Peer 4.6.2 Cliente – servidor 4.6.3 Jerárquica de cliente – servidor 4.6.4 Computación distribuida

4.7

Priorización del flujo

4.8 La especificación de flujo 4.8.1 FLOWSPEC algoritmo 4.8.2 Servicio de planificación y capacidad de 4.9 Ejemplo de aplicación de análisis de flujo

4.10 Conclusions 4.11 Exercises

160

4 Análisis de flujo Los resultados del análisis de requisitos, la especificación de requisitos y requisitos mapa: enumerar y describir los requisitos que se han reunido y derivado de una red. Muchos de estos son requisitos de funcionamiento (capacidad de demora y RMA) para los usuarios, sus aplicaciones y dispositivos. Estos requisitos de rendimiento, junto con las ubicaciones de los usuarios, aplicaciones y dispositivos en el mapa de necesidades, forman la base para estimar donde tráfico fluirá a través de la red. Análisis de flujo es el proceso de caracterización de los flujos de tráfico de una red: donde es probables que ocurra y qué niveles de rendimiento que se requieren.

La intención del análisis de flujo no es mostrar cada flujo posible en una red, sino mostrar aquellos flujos que tendrán el mayor impacto en la arquitectura de red y el diseño. Esto es a menudo una pequeña fracción del conjunto total de los flujos de una red.

4.1 Objetivos En este capítulo aprenderá a identificar y caracterizar los flujos de tráfico. Discutimos flujos individuales, compuestos y críticos y cómo determinar cuándo cada uno se aplica. Usted aprenderá los mecanismos para ayudar a identificar y caracterizar los flujos, incluyendo fuentes de datos y modelos de flujo y fregaderos. Por último, usted aprenderá acerca de las especificaciones de flujo, donde se combinan los requisitos de rendimiento para un flujo o grupo de flujos. Especificaciones de flujo se utilizan como insumo para los procesos de diseño y arquitectura de red, más adelante en este libro.

4.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con el cliente – servidor, peer-to-peer, computación distribuida y otros modelos para cómo interactúan uno con el otro aplicaciones y dispositivos. 161

4.2 Fondo Ahora que ya tenemos el usuario, aplicación, dispositivos y requerimientos de red desarrollado, listados y mapeados en la especificación de requisitos, además analizamos estos requisitos basados en sus características de extremo a extremo. Utilizamos el concepto de un flujo, que, para una conexión de extremo a extremo, tiene direccionamiento constante y requerimientos de servicio, a requisitos de rendimiento se combinan en una forma útil. Estas características son analizadas y combinadas, por flujo, en una especificación de flujo o un flowspec. Se utiliza para la capacidad y planificación de servicios. Este capítulo presenta corrientes y conceptos de flujo, fuentes de datos, fregaderos y modelos de flujo que nos ayudará a identificar, tamaño y describir los flujos. También desarrollamos los requisitos de funcionamiento acumulado para cada flujo.

4.3 Flujos de Flujos de (también conocido como flujos de tráfico o flujos de datos) son conjuntos de tráfico de red (aplicación, protocolo e información de control) que tienen atributos comunes, tales como dirección de origen/destino, tipo de información, direccionalidad, u otra información end-to-end. Figura 4.1 ilustra este concepto. Información dentro de un flujo se transmite durante una sola sesión de una aplicación. Los flujos son end-to-end, entre fuente y destino usuarios de aplicaciones de dispositivos. Ya que pueden ser identificados por su información end-to-end, pueden ser directamente vinculados a una aplicación, dispositivo o red, o asociadas a un usuario final. También podemos examinar los flujos por enlace o por la red. Esto es útil cuando queremos combinar las exigencias de caudal a nivel de red o elemento de red.

Figura 4.1 flujo de atributos aplicarán End-to-End y a través de red

Flujos de

Características de flujo

Capacidad (por ejemplo, ancho de banda) Requisitos de desempeño

Retardo (p. ej., latencia) Fiabilidad (por ejemplo, la disponibilidad de) Calidad de niveles de servicio

Importancia / niveles de prioridad

Proveedor de empresa de negocios Política Direccionalidad Grupos comunes de usuarios, aplicaciones, dispositivos Programación (por ejemplo, hora del día)

Otros Protocolos utilizados Direcciones o puertos Requisitos de seguridad y privacidad Características comunes de flujo de la figura 4.2

Características de flujo comunes se muestran en la figura 4.2. Análisis de flujo es una parte integral del proceso general de análisis. Los flujos son donde los requisitos de rendimiento, servicios y métricas de servicio se combinan con información de ubicación para mostrar donde se necesitan rendimiento y servicio en la red. Análisis de flujo ofrece una perspectiva end-to-end en requisitos y programas donde requisitos se combinan e interactúan. También proporciona información en los grados de jerarquía y diversidad en la arquitectura y el diseño. Además, como veremos en el proceso de diseño, este análisis también proporciona información que puede ser útil en la elección de estrategias de interconexión, tales como mecanismos de conmutación, enrutamiento o híbrido. Más corrientes son bidireccionales y pueden ser representadas como sea una flecha doble faz única, con uno o dos conjuntos de requisitos de desempeño, o como dos separados flujos, cada uno con su propio conjunto de requisitos. Una flecha de un solo lado con un conjunto de requisitos de desempeño representa un flujo unidireccional. Figura 4.3 muestra estos casos. Flujos proporcionan una perspectiva diferente sobre la circulación de tráfico en redes: tienen lógica así como componentes físicos; y permiten el tráfico a acoplarse con los usuarios, aplicaciones o dispositivos. Los flujos son cada vez más importantes en el análisis, arquitectura y procesos de diseño. 250 kb/s

Flujo 4 1 mb/s Flujos de la figura 4.3 se representan como unidireccional o bidireccional flechas con requisitos de rendimiento

Examinamos dos tipos de flujos: individuales y compuestos. Vamos a ver que la agregación de los requerimientos y flujos en la red debido a la jerarquía conduce a flujos de compuestos, y que esto puede suceder en la red de acceso, así como en la columna vertebral.

4.3.1 Flujos individuales y compuestos Un flujo individual es el flujo de una sola sesión de una aplicación. Un flujo individual es la unidad básica de los flujos de tráfico en este libro; son ya sea considerados individualmente o combinados en uno compuesto. Cuando un flujo individual ha garantizado requisitos, esos requisitos generalmente se quedan con el flujo individual y no se consolidan con otros requisitos o caudales en un compuesto (Figura 4.4). Esto se hace para que requerimientos garantizados de flujo pueden ser tratados por separado del resto de los flujos. Corrientes individuales se derivan directamente de la especificación de requisitos, o se estiman de nuestro mejor conocimiento sobre la aplicación, usuarios, dispositivos y su ubicación.

Figura 4.4 flujo Individual para una sola aplicación con requisitos de garantía

Flujos de

Figura 4.5 ejemplo flujos compuestos

Un flujo compuesto es una combinación de requisitos de múltiples aplicaciones, o de las corrientes individuales, que comparten un enlace común, ruta o red. Más corrientes en una red son compuestos (Figura 4.5). Más ejemplos de los flujos se presentan en la figura 4.6. El primer ejemplo es un flujo individual, que consiste en un requisito de retardo unidireccional para una sola sesión Aplicación 1: 100 ms de retardo unidireccional

Aplicación 1: 100 kb/s contra la corriente 500 kb/s aguas abajo Aplicación 1: Uso aguas arriba de 500 kb/s 2: 1 mb/s bidireccional aplicación 3: 100 ms de retardo ida y vuelta

Aplicación 1: Perfil de desempeño 1 Figura 4.6 flujo ejemplos

de una aplicación. Tenga en cuenta que este flujo es unidireccional. El segundo ejemplo es también de un flujo individual, pero en este caso se dan los requerimientos de capacidad en cada dirección. Puesto que son diferentes, se enumeran independientemente. Las definiciones de aguas arriba y aguas abajo, como se utiliza aquí denotan direccionalidad basada en el origen y el destino del flujo, donde aguas arriba indica la dirección hacia la fuente y aguas abajo de la dirección hacia el destino. Aguas arriba es a menudo hacia el núcleo de la red, mientras que aguas abajo suele ser hacia el borde de la red, particularmente en redes de proveedores de servicio. Otra forma para mostrar un flujo bidireccional con dos flechas separadas, uno arriba y otro aguas abajo, cada uno con su propio requisito de desempeño. El tercer ejemplo es un flujo compuesto, listado de requisitos de tres aplicaciones separadas en la misma fuente. El ejemplo anterior utiliza un perfil de desempeño para describir requerimientos de performance de flujo. Un perfil es de uso frecuente cuando muchos flujos tienen el mismo requisito, como esto hace más fácil a los mismos requisitos se aplican a varios flujos: un puntero al perfil es suficiente para describir los requisitos, en vez de haberlos escrito cada vez. Esto es especialmente útil cuando los requerimientos son largos o cuando estén de acuerdo en muchos flujos. El flujo en este ejemplo podría ser un individuo o un flujo compuesto, según el contenido del perfil. Requisitos de rendimiento para flujos individuales y compuestos flujos se determinan a través del desarrollo de una especificación de flujo de la red, que se discute al final de este capítulo.

4.3.2 Corrientes críticas Algunos flujos pueden considerarse más importantes que otros, en que son más altos en rendimiento o tienen requisitos estrictos (por ejemplo, misión crítica, velocidad crítica, en tiempo real, interactivo y de alto rendimiento), mientras que algunos flujos pueden servir a los usuarios más importantes, sus aplicaciones y dispositivos. Esas corrientes se llaman corrientes de críticas. En este capítulo veremos cómo determinar cuando los flujos son críticos. Cuando priorizar que flujos de llamar la atención en el diseño y arquitectura de redes, flujos críticos generalmente vienen primeros. Esto suele ser el caso; sin embargo, flujos individuales garantizados requisitos podrían también considerar en primer lugar en la arquitectura y el diseño. Priorización de flujos se discute al final de este capítulo. Los flujos se describen de esta manera para hacerla más fácil de comprender y combinar los requisitos. Flujos de compuestos combinan los requisitos de los flujos individuales, mientras que los flujos individuales pueden mostrar garantiza los requisitos que deben ser considerados a lo largo de la ruta de extremo a extremo del flujo. Todos estos flujos son

importante en la arquitectura y el diseño de la red. Las descripciones de los tipos de flujos que desarrollamos en la especificación de flujo nos ayudan a definir la arquitectura y escoger las tecnologías y servicios que mejor se adapten a las necesidades del cliente.

A lo largo de este capítulo se analizan los requerimientos de flujo para determinar donde se aplican y cuándo contribuyen a los flujos de compuestos, y, si lo hacen, cómo combinar sus requisitos de funcionamiento en consecuencia. Algunas redes tienen flujos que indican el rendimiento de la solo-grada, otros tienen flujos que indican el rendimiento de varios niveles, y todavía otros predecibles (estocásticos) y funcionamiento garantizado. A menudo los pocos flujos que requieren un rendimiento alto, predecible y garantizado son los que impulsan la arquitectura y el diseño de un servicio (capacidad de demora y RMA) perspectiva, mientras que todos los flujos de conducen la arquitectura y el diseño de una capacidad punto de vista. Los procesos de diseño y arquitectura de servir de estas perspectivas.

4.4 Identificación y desarrollo de flujos de Flujos generalmente pueden ser identificados y desarrollados a partir de información en la especificación de requisitos: usuario, aplicaciones, dispositivos y requisitos de la red; comportamiento del usuario y la aplicación (modelos y patrones de uso); usuario, la aplicación y la información de la ubicación del dispositivo; y requisitos de funcionamiento. Es la más completa de esta información, mejor será los resultante de los flujos. En este punto en el proceso de análisis tenemos conjuntos de requisitos y asignaciones de aplicación y/o dispositivo de localizaciones. No hemos hecho ninguna opciones de redes tecnologías, dispositivos de red o proveedores. Es importante que durante el proceso de análisis de flujo no restringir flujos en redes, topologías y tecnologías. Queremos ser libres en la determinación de las composiciones y los lugares de flujos para nuestra red, para que los flujos de conducen nuestra arquitectura y diseño de opciones. Así, los flujos son determinados basados en las necesidades y ubicaciones de las aplicaciones y dispositivos que generan (fuente) o cancelar (fregadero) cada flujo de tráfico. El proceso de identificación y desarrollo de flujos consiste en identificar una o más aplicaciones o dispositivos que usted crea se generan o poner fin a los flujos de tráfico. Una vez que ha elegido que aplicaciones y dispositivos para centrarse en, utilice sus requisitos de la especificación de requisitos y sus ubicaciones en el mapa de necesidades. Basado en cómo y dónde se utilizan cada dispositivo y aplicación, pueden ser capaces de determinar los dispositivos que generan flujos y dispositivos que terminan corrientes (flujo de fuentes y sumideros). Algunos modelos comunes de flujo se encuentran en la sección 4.6 para ayudarle con este proceso. Una vez que han identificado cada flujo y determina su composición y su ubicación, se combinan los requisitos de rendimiento de los flujos en una especificación de flujo. Este proceso se muestra en la figura 4.7. Desde una perspectiva de aplicación, algunos enfoques comunes a la identificación de los flujos incluyen: • Enfoque en una aplicación particular, grupo de aplicación, dispositivo o función (p. ej.,

videoconferencias o almacenamiento) • Desarrollo de un "perfil" de aplicaciones comunes o las que se pueden aplicar a través de una

población de usuarios • Elegir el top N (por ejemplo, 3, 5, 10, etc.) aplicaciones para aplicarse en toda la red

Usted puede considerar algunos o todos los enfoques para su red. Cada enfoque se describe en las secciones siguientes.

Figura 4.7 el proceso de identificación y desarrollo de flujos de

4.4.1 Centrarse en una aplicación Particular Al centrarse en una aplicación, grupo de aplicación, dispositivo o función, la idea aquí es considerar una o más aplicaciones que probablemente conducirá a la arquitectura y el diseño, es decir, aquellos que son críticos, tarifa-críticas de alto rendimiento en tiempo real, interactivo, previsibles y garantizados. Al centrarse en una o varias aplicaciones, puede pasar más tiempo determinar sus flujos, en lugar de separarse hacia fuera de su tiempo a través de muchas aplicaciones. Elija qué y seleccionar la información relevante de la especificación de requisitos. Ejemplo: Migración de datos De especificación de requisitos, para una sola sesión de cada aplicación: Aplicación 1: Organizar datos de dispositivos de usuario Capacidad 100Kb/s; Retrasar el desconocido; Fiabilidad 100% Aplicación 1: Migración de datos entre servidores Capacidad 500Kb/s; Retrasar el desconocido; Fiabilidad 100% Aplicación 2: Migración a almacenamiento remoto (terciario) Capacidad 10Mb/s; Demora n /; Fiabilidad 100% Puede utilizar la información de ubicación en un mapa donde están los usuarios, aplicaciones y dispositivos y desarrollar un mapa si no tienes uno. Figura 4.8 es un ejemplo de tal mapa. Con la información sobre el comportamiento del usuario y la aplicación, determinar o estimar dónde se producirán flujos. Esto puede ser entre las redes, los grupos de dispositivos (mejor), o dispositivos individuales (mejor). Figura 4.9 muestra donde los flujos se producirán entre los dispositivos de aplicación 1. Una vez que los flujos se asignan, aplicar información de rendimiento para cada flujo. Figura 4.10 se muestra para la porción del Campus Central del almacenamiento de información del entorno de aplicación. Considerando que la figura 4.9 muestra flujos entre dispositivos, figura 4.10 simplifica este punto de vista, mostrando los flujos entre los edificios. Puede utilizarse cualquiera de los métodos, dependiendo del tamaño del ambiente y el número de flujos que necesita mostrar. Generalmente el método entre el dispositivo (Figura 4.9) se utiliza primero para estimar donde los flujos va a ser, y entonces el segundo método (Figura 4.10) se utiliza para simplificar el diagrama de flujo. número dado

67 Campus central

Figura 4.8 mapa de localizaciones de dispositivo de una red

Figura 4.9 flujos estimados entre los dispositivos de aplicación 1

Figura 4.10 flujos F1, F2 y F3 representan los requisitos de funcionamiento de sesión única para cada edificio de aplicación 1. En algún momento de este proceso los requisitos de funcionamiento tendrán que ser modificadas para representar el rendimiento estimado necesario por todos los usuarios en cada edificio (40, 67 y 45 usuarios en la

F4: 500 Kb/s, 100% Figura 4.10 rendimiento información añadida a los flujos del Campus Central para aplicación 1

edificios en Campus Central). F4 representa los requisitos de funcionamiento para el flujo de servidor – entre el centro y Campus Norte.

Tenga en cuenta que en esta figura las corrientes F1 y F2 son entre edificios A B y C, mientras que flujo F3 es entre dispositivos. Puesto que los dispositivos de 45 usuario y cuatro servidores en el mismo edificio, tenemos que mostrar los flujos entre los dispositivos. Si nos muestra los flujos dentro de edificio C, se vería como la figura 4.11. Este diagrama también presenta un punto de agregación de flujo, que nos permite mostrar varios flujos consolidados en un lugar. Esto es útil en el proceso de diseño,

Figura 4.11 Campus Central los flujos de aplicación 1 ampliados con edificio C Punto de agregación de flujo (tecnologías de red se pueden aplicar en este punto durante el proceso de diseño)

entre los edificios Figura 4.12 consolidación de flujos mediante un punto de agregación de flujo

Cuando buscamos en tecnologías y estrategias de interconexión para esos lugares en la red. Por ejemplo, la figura 4.12 muestra como lucirá flujos entre edificios con y sin un punto de agregación de flujo.

4.4.2 Desarrollo de un perfil A veces un conjunto de usos comunes se aplican a un grupo de usuarios o para el conjunto de los usuarios. Cuando este es el caso un perfil o una plantilla puede ser desarrollada para esas aplicaciones, y cada flujo que encaja en el perfil se identifica con la etiqueta de ese perfil. Así, en lugar de tratar de replicar información de flujo para flujos similares, usted puede utilizar el perfil, ahorrando tiempo y esfuerzo.

También hay veces cuando los flujos tienen los mismos requisitos de rendimiento, independientemente de si comparten el mismo conjunto de aplicaciones. Cuando los flujos tienen los mismos requisitos de desempeño, un perfil puede utilizarse para simplificar sus datos, así. Figura 4.13 muestra un perfil aplicado en toda la población de usuarios de aplicación 1. En lugar de mostrar requisitos de funcionamiento idéntico a cada flujo, se muestra un perfil común para flujos con los mismos requisitos de desempeño. Esto ayuda a reducir la duplicación de la información en el mapa, también reduciendo el desorden. En esta figura, P1 es la etiqueta asociada a flujos de tener los siguientes requisitos de desempeño: capacidad = 100Kb/s, fiabilidad = 100%. Hay seis flujos en este diagrama con los requisitos de desempeño, que se han etiquetado como P1. Otros flujos en esta figura tienen diferentes prescripciones. F4 de flujo (también se muestra en las figuras 4.10 y 4.11) tiene requisitos de funcionamiento diferentes: capacidad = 500kb/s, fiabilidad = 100%. Flujo 5 combina el rendimiento

Figura 4.13 un perfil de desempeño (P1) aplicado a los múltiples flujos con el mismo rendimiento Características

requerimientos de los 51 usuarios (que, para la aplicación 1, P1) con los de los dos servidores en ese edificio. Flujo F6 combina los requisitos de rendimiento de 14 usuarios (de nuevo, esto sería P1) con que el dispositivo de vídeo digital. F7 como F5, combina los requisitos de rendimiento de los usuarios (88 en este edificio) con los de los dos servidores de cálculo. Observe que la figura 4.13 muestra los flujos como flechas entre edificios y entre dispositivos dentro de un edificio (excepto flujo F4, que en este ejemplo es más fácil de mostrar como un flujo entre los dispositivos que como un flujo entre edificios). También podríamos elegir mostrar los flujos sólo entre dispositivos, como en la figura 4.9. Si se comparan estas dos figuras, verá que muestran las flechas entre los edificios simplifica el diagrama. Sin embargo, puede que necesite complementar tal un diagrama con los diagramas de flujos dentro de edificios, como se muestra en la figura 4.11.

4.4.3 Elegir las aplicaciones Top N Por último, elegir el top N aplicaciones para su red es una combinación de los dos primeros enfoques. Es similar a la primera aproximación, sin embargo; en lugar de una aplicación en particular (o tal vez dos aplicaciones), se utiliza tres, cinco o quizá diez. También es similar a la

segunda aproximación, en que el resultado también puede ser un perfil de aplicación. Estas aplicaciones son el número de "top N"en términos de contribuir con el éxito de esa organización, que puede ser inferido por los grados de uso, de usuarios, número de servidores de dispositivos, o requisitos de desempeño. Ejemplo: Mejores 5 aplicaciones 1. Navegación por la web 2. Correo electrónico 3. Transferencia de archivos 4. Procesamiento de textos 5. Transacciones de la base de datos Este enfoque reduce el conjunto de aplicaciones posibles a un número que puede ser analizada. Sin embargo, siempre eliminan aplicaciones de este sistema, usted necesita hacer la pregunta, "Si cumple con los requisitos de las aplicaciones de N superior, se respetan los requisitos para aquellas aplicaciones que eliminé?" La intención de este enfoque es determinar qué aplicaciones representan los requisitos más importantes para esa red. Estas aplicaciones "top N" están probables que los controladores de rendimiento de la red. Como tal, si cumple con las necesidades de estas aplicaciones, son capaces de satisfacer las necesidades de todas las aplicaciones de esa red. Esto se describe con más detalle durante el desarrollo de la especificación de flujo. La lista de aplicaciones "top N" debe ser tan precisa como lo puede hacer. Por ejemplo, aplicación 5 (transacciones de base de datos) puede ser entrada de datos de la tarjeta de registro en una base de datos ERP. Esta sería una descripción más exacta, dando por resultado información más precisa de composición y ubicación de flujo. Siempre que sea posible, incluir los escenarios de uso para cada aplicación. También puede utilizar diferentes enfoques para diferentes partes de la red. Por ejemplo, es común incluir las aplicaciones de N superior que se aplican en todas partes, así como perfiles de lugares seleccionados y centrarse en una aplicación, dispositivo o grupo en otros lugares, como en la figura 4.14. Figura 4.14 un proyecto puede incorporar múltiples enfoques en la elección de aplicaciones

4.5 Fregaderos y fuentes de datos Fregaderos y fuentes de datos pueden ayudar a proporcionar direccionalidad a los flujos. Un origen de datos genera un flujo de tráfico, y un fregadero de datos termina un flujo de tráfico. Para ayudar a Mostrar datos fuentes y sumideros de un diagrama, se utiliza la Convención que se muestra en la figura 4.15. Fuentes de datos son representadas como un círculo con un punto en el centro, y un sumidero de datos se representa como un círculo con una cruz (es decir, estrella o asterisco) en el centro. Estas son representaciones de dos dimensiones de un plano con una flecha saliendo de ella, como en el tráfico que fluye de una fuente, o un plano con una flecha que va en él, como en el tráfico que fluye en un fregadero. Mediante el uso de estos símbolos podemos Mostrar datos fuentes y sumideros en el mapa bidimensional, sin necesidad de flechas.

Casi todos los dispositivos en una red de producirán y aceptan datos, actuando como fuentes y sumideros, y hay algunos dispositivos que normalmente actúan como una fuente o fregadero. Además, un dispositivo puede ser principalmente un origen de datos o un fregadero para una aplicación particular. Algunos ejemplos de fuentes de datos son dispositivos que se mucho de computación o procesamiento y generan grandes cantidades de información, tales como servidores, mainframes, sistemas paralelos de computación o informática racimos. Otros dispositivos (especializadas), como cámaras, equipo de producción de vídeo, servidores de aplicaciones, instrumentos médicos, no necesariamente hacen un montón de informática (en el sentido tradicional) pero todavía pueden generar un montón de datos, video y audio que se transmitirá en la red (Figura 4.16). Un buen ejemplo de un fregadero de datos es un dispositivo de archivo o almacenamiento de datos. Esto puede ser un solo dispositivo, actúa como un front-end para los grupos de discos o dispositivos de cinta. Dispositivos que manipularán o exhibición grandes cantidades de información, como edición de vídeo o dispositivos de exhibición, también actúan como sumideros de datos (Figura 4.17).

Figura 4.15 convenciones para datos de fuentes y sumideros

Fuentes de datos de ejemplo de figura 4.16

Ejemplo 4.1. Datos fuentes y sumideros de datos aplicaciones de migración. Como ejemplo, vamos a considerar las solicitudes de migración de datos. Hay que recordar que la figura 4.8 muestra información de la ubicación del dispositivo para estas aplicaciones. En este mapa se muestran servidores de almacenamiento y cálculo, una fuente de vídeo y grupos de dispositivos de escritorio para cada edificio. Tenga en cuenta que se da un número total de dispositivos de escritorio; Esto se hace para simplificar el mapa y los flujos. Si se necesita más detalle, este grupo podría ser separado en varios grupos, basados en sus requerimientos, o dispositivos solo se pueden separar hacia fuera. Si es necesario, se pudo generar un nuevo mapa para sólo ese edificio, con substancialmente más detalles. Este servicio tiene dos aplicaciones. Aplicación 1 es la frecuente migración de datos en ordenadores personales de los usuarios, servidores y otros dispositivos, a servidores de almacenamiento en cada escuela. Como parte de esta aplicación, se migran los datos desde el servidor en el Campus Central en el servidor en el Campus Norte. El servidor en el Campus sur es también el servidor de archivo (o a largo plazo) de estos planteles. Aplicación 2 es la migración de datos que se han recopilado durante un período de tiempo (por ejemplo, 1 día) desde el servidor en el Campus Central el servidor de archivo en el Campus sur. Cuando, para la aplicación 1, sumamos los datos fuentes y sumideros figura 4.13, obtenemos el diagrama en la figura 4.18. En esta figura están marcados todos los dispositivos como un origen de datos, fregadero o ambos. Todos los dispositivos de usuario en cada campus son fuentes de datos. Los servidores en Campus Central actúan como un receptor de datos para flujos de dispositivos de usuario en ese campus y como un origen de datos cuando migra los datos al servidor en Campus Norte (flujo F4). El servidor en el Campus sur es una

Figura 4.18 datos fuentes, sumideros y flujos añadidos a la primera parte de la aplicación

datos del fregadero para flujos de usuario en ese campus y los servidores en el Campus Norte son fregaderos de datos para todos los dispositivos en ese campus, incluyendo video digital y servidores, así como para el flujo de F4 del Campus Central. Con las fuentes y sumideros en el mapa, junto con las flechas entre ellos para indicar el potencial de los flujos de tráfico, estamos empezando a tener una idea de donde se producen las corrientes en esta red para esta aplicación. Hacemos lo mismo para 2 aplicaciones, con el resultado que se muestra en la figura 4.19. Para esta parte de la aplicación de los dispositivos de escritorio y fuente de vídeo no participan, por lo que no se muestran como fuentes o sumideros de datos. El servidor en Campus Central que era un receptor de datos para aplicación 1 se convierte en una fuente de datos para 2 aplicaciones, enviar datos al servidor del archivo (se muestra como un sumidero de datos). Los flujos de esta parte de la aplicación están mucho más sencillos, simplemente un flujo único entre el servidor de almacenamiento y el archivo dispositivo. Esto aparece de dos maneras: como un flujo entre edificios (opción 1, la Convención estándar utilizada hasta ahora en este ejemplo) y como un flujo entre dispositivos en edificios separados (opción 2). Opción 2 no es práctica común, se utiliza aquí puesto que hay solamente dos dispositivos (y un flujo) para esta aplicación. Estas aplicaciones se muestran como eventos separados para clarificar los flujos y los roles de los servidores de almacenamiento de información. Podríamos, sin embargo, juntamos ambas partes de la aplicación en el mismo mapa. Queremos que el mapa resultante esté todavía claro cuando los dispositivos son sumideros y fuentes de datos.

Figura 4.19 datos fuentes, se hunden y fluye mayor aplicación 2 (dos opciones que se muestran)

Figura 4.20 aplicación de migración de datos con servidor – flujos aislados

Una manera de simplificar este mapa es centrarse sólo en flujos entre servidores de almacenamiento, fuentes de datos y se hunde. Figura 4.20 se muestra este caso, con ambas aplicaciones en el mismo mapa.

Usted puede haber notado en nuestro ejemplo que flujos ocurren en diferentes momentos del día y pueden variar en horario (cuando ocurren), frecuencia (la frecuencia con que ocurran) y la duración (cuánto tiempo duran). La ocurrencia de flujos de tráfico puede ser cíclica (por ejemplo, cada lunes por la mañana antes de 10., al final de cada mes, o durante el cierre de fin de año). Comprender cuando se presentan flujos y cómo inciden los negocios de sus clientes o funcionamiento es crítico. Por ejemplo, si el 90% de los ingresos de un negocio se genera durante las últimas cuatro semanas antes de Navidad, puede que necesite para el desarrollo de flujo de foco sobre lo que está sucediendo a las aplicaciones durante ese tiempo. Esto conduce al concepto de desarrollo de escenarios de peor casos y el uso típico. Esto es similar a desarrollar para un rendimiento único nivel o varios nivel, como se analizó en el capítulo

3. Escenarios de peor casos son como el ya mencionado — de un negocio cuyos ingresos son altamente estacional. Esto es similar a desarrollar para el mayor rendimiento aplicaciones y dispositivos, en la que usted se centran en tiempos cuando la red requiere su mejor actuación para apoyar la labor. Arquitectura/diseño una red para el peor escenario posible puede ser cara y resultará en exceso de ingeniería la red para la mayor parte de su ciclo de vida. Por lo tanto, el cliente debe ser totalmente consciente de las razones y de apoyo, edificio hacia peor. Escenarios de uso típicos describen una media carga de trabajo (típico) de la red. Esto es similar a desarrollar para el desempeño de la solo-grada, que centran en veces cuando media, todos los días se está trabajando. Recuerde del capítulo 3 que solo nivel de rendimiento se centra en las aplicaciones y dispositivos que sirven en general y que conforman un nivel de fondo de tráfico en la red. Se desarrollan escenarios a menudo peores tanto uso típico para una red. Utilizando datos de fuentes y sumideros para ayudar a mapa de flujos para una aplicación proporciona un gran comienzo para generar los flujos de la red. Modelos de flujo, que se describe a continuación, son otra gran herramienta que puede utilizar para ayudar a describir los flujos.

4.6 Modelos de flujo Otro método para ayudar a describir los flujos en la red es compararlos con modelos de flujo general, bien conocidos. Modelos de flujo son grupos de flujos que exhiben características de comportamiento específicas y consistentes. Los flujos dentro de un modelo de flujo se aplican a una sola aplicación. Direccionalidad, la jerarquía y la diversidad son las principales características de los modelos de flujo. Direccionalidad se describe la preferencia (de falta de ella) de un flujo que más requisitos en una dirección que otra. Jerarquía y la diversidad se basan en las definiciones del capítulo 1. Mientras que diseños y arquitecturas de red típicamente tratan flujos de tráfico como con requisitos iguales en cada dirección, encontramos que muchos flujos (especialmente de aplicaciones más nuevas) tienen requisitos muy diferentes en cada dirección. Más corrientes son asimétricas, y algunas tecnologías de acceso y de transmisión (como bucle de abonado digital [xDSL] o WDM) pueden ser optimizados para esos flujos. Modelos de flujo ayudan a describir los grados de jerarquía y diversidad de los flujos de aplicaciones. Muestran donde se combinan los flujos, donde se pueden agrupar juntos y donde los flujos se producen entre pares, que son dispositivos en el mismo nivel en la jerarquía. Ellos también nos pueden ayudar a identificar que los flujos son corrientes de críticas; Estos, como usted recordará, se consideran más importantes que otros, en que son superiores en rendimiento, tienen requisitos estrictos o servir más importante los usuarios, aplicaciones y dispositivos. Modelos de flujo también pueden ser útiles para ayudar a rápidamente identificar y clasificar los flujos en un entorno, por lo que fácilmente podemos reconocer sus características de flujo. De esta manera son como grupos de aplicaciones, discutidos en el capítulo 2.

Modelos de flujo que examinamos son: • Peer-to-peer

• Cliente – servidor • Jerárquica de cliente – servidor • Distribuido de computación

Para cada modelo tenemos en cuenta la direccionalidad y la jerarquía de sus flujos. También, cuando sea posible, identificamos que fluye en cada modelo es críticas o importantes, de corrientes. Estos modelos de flujo son un subconjunto de los muchos modelos posibles que se podrían utilizar para caracterizar los flujos de la red. Nosotros podríamos incluir, por ejemplo, flujos en tiempo real (o casi en tiempo real o interactivos) como un modelo, así como medios de transmisión. Le animamos a desarrollar una lista exhaustiva de los modelos de flujo para sus proyectos de la red.

4.6.1 Peer-to-Peer Nuestro primer modelo de flujo, a pares, uno es donde las aplicaciones y los usuarios son bastante coherentes en sus comportamientos de flujo a través de la red. Son, en efecto, sus compañeros, que actúan en el mismo nivel en la jerarquía. Puesto que (los usuarios o aplicaciones) son bastante coherentes, sus flujos son también bastante consistentes. Así, podemos considerar los flujos en un modelo peer-to-peer flujo equivalente (Figura 4.21). Esto tiene dos implicaciones importantes: • No podemos distinguir entre flujos en este modelo. Por lo tanto, cualquiera de los flujos o

ninguno de los flujos es fundamental • Puesto que los flujos sean equivalentes, puede ser descritos por una especificación simple

(por ejemplo, perfil)

Figura 4.21 flujo de Peer-to-Peer modelo

Figura 4.22 un ejemplo de Peer-to-Peer fluye en el Internet temprano

Hay varios ejemplos de comportamiento del flujo de peer-to-peer. El primero es el Internet temprano, una parte de la cual se muestra en la figura 4.22. En el Internet temprano, aplicaciones como FTP y telnet eran predominantes, y cada dispositivo de la red era una potencial fuente y destino de los flujos para estas aplicaciones. Otro ejemplo es de uso compartido de archivos aplicaciones en Internet. Básicamente, los dispositivos se comunican directamente con cada uno en cualquier lugar se considera peer-to-peer. El modelo de flujo de peer-to-peer es nuestro defecto cuando no tenemos ninguna otra información sobre los flujos en nuestra red. En un sentido, es parte del caso degenerado para ver nuestro mapa de requisitos (ya que no existen requisitos específicos de flujo que pueden ser determinados). Este modelo de flujo puede utilizarse también para describir flujos cuando todos los usuarios de un grupo necesitan igualdad de acceso a uno con el otro para una aplicación. Además de las aplicaciones de uso compartido de archivos y acceso remoto ya descritas, también puede ser un multimedia, tele∗aplicación de servicios (por ejemplo, teleseminarios, telelearning, teleconferencia), donde cualquiera de los participantes puede fuente o fregadero datos o de cualquier otro participante. Aunque cada uno de los tele∗servicios sólo señaló puede considerarse una aplicación de uno a muchos, hay componentes de cada uno que se puede aplicar como un conjunto de conversaciones uno a uno. Por ejemplo, mientras que telelearning consiste en un número de usuarios (estudiantes) transmite desde y a un maestro y recibe otro

Figura 4.23 Peer-to-Peer fluye en un ambiente de Telelearning

componente de esta aplicación es la capacidad de tener conversaciones de lado entre los estudiantes. Esta parte de la aplicación es peer-to-peer (Figura 4.23). Este modelo de flujo es útil, en que indica que un perfil de desempeño puede usarse para esos flujos, y que hay flujos críticos no (o varios) para esa aplicación.

4.6.2 Cliente – servidor El modelo de flujo de cliente – servidor es actualmente el modelo más generalmente aplicable. Este modelo tiene direccionalidad y jerarquía. Los flujos en este modelo son bidireccionales, entre clientes y el servidor, en forma de peticiones y respuestas. Este modelo de flujo es cliente – servidor que los flujos son asimétricos y jerárquico enfocado hacia el cliente. Por lo tanto, las solicitudes tienden a ser pequeñas en relación con las respuestas. Dependiendo del tipo de aplicación, los flujos pueden considerarse casi unidireccionales, desde el servidor a los clientes. Figura 4.24 ilustra el modelo de flujo de cliente – servidor. Puesto que los flujos en el modelo cliente – servidor están asimétricos, con los flujos predominantes o importantes en la dirección del servidor a los clientes, el servidor puede ser considerado una fuente de datos, y los clientes son fregaderos de datos. El servidor se mostrarán como origen de datos en el mapa de necesidades, con los flujos de generación de él a sus clientes en otras áreas del mapa. Puesto que los flujos predominantes o importantes desde el servidor a los clientes, son los flujos críticos para este modelo. Cuando hay un requisito de transmitir información a varios clientes al mismo tiempo, la multidifusión en algunas capas de la red debe considerarse para optimizar flujos para este modelo.

Figura 4.24 modelo de flujo de cliente – servidor

Este modelo es la visión tradicional de las operaciones de cliente – servidor, ejemplificado por aplicaciones de ERP como SAP y aplicaciones de comercio electrónico. Aplicaciones tales como éstos son muy dependientes de rendimiento de la red cuando están configurados para trabajar a través de considerables distancias, como cuando una empresa se dispersa a través de múltiples localizaciones, que abarcan ciudades, Estados o países. Si la red no admite correctamente aplicaciones cliente – servidor, el cliente debe recurrir a la distribución de la arquitectura cliente – servidor (por ejemplo, ERP distribuido), que puede ser cara. Edición de vídeo es un ejemplo de un modelo de flujo de cliente – servidor. Un servidor de video puede almacenar vídeo a editar, y clientes realizan peticiones a ese servidor de video para editar. El servidor pasa el video a los clientes, que pueden ser enviados hasta el servidor una vez, o pueden ser enviados en otro lugar para más procesamiento (Figura 4.25). Otro punto de vista de los flujos de cliente – servidor es con aplicaciones Web. Si bien el Internet temprano comenzó con peer-to-peer flujos de aplicaciones tales como FTP y telnet, este uso evolucionó para convertirse en más cliente-servidor-como con el uso de servidores FTP, seguida por aplicaciones tales como gopher y Archie. Ahora, con el uso generalizado de aplicaciones Web, muchas corrientes en el Internet son entre servidores Web y sus clientes. TCP/IP asume red más funciones del sistema operativo (NOS), servicios de impresión y archivo a través de Internet y las redes empresariales se volverá más cliente – servidor orientado. Por ejemplo, en los primeros días, una persona que quería acceder a la información de una organización habría utilizado la aplicación FTP a un sitio conocido para descargar información. Luego esto cambió en acceder a un servidor FTP o gopher y luego para acceder a un servidor Web. Hoy en día una persona puede acceder a grandes cantidades de información en una organización sin jamás entrar en la red de la organización, a través de acceso a servidores Web externos.

Figura 4.25 ejemplo de flujos de cliente – servidor

Sin embargo, un mejor modelo de flujo de tráfico Web tiene varios niveles de gradas, con flujos de tráfico dentro de algunos de los niveles. Este es el modelo jerárquico de cliente – servidor, descrito en la sección siguiente.

4.6.3 Jerárquica de cliente – servidor Como los flujos dentro de un modelo de flujo de cliente – servidor más jerárquica, en cuanto a la adición de capas o niveles, a los flujos, entonces su comportamiento se puede representar como un modelo de flujo jerárquico de cliente – servidor. Un modelo de flujo de cliente – servidor jerárquico tiene las características de un modelo de flujo de cliente – servidor, pero también tiene varias capas o niveles, de entre los servidores. En este modelo también puede haber flujos desde un servidor a un dispositivo de servidor o de gestión de apoyo, como se muestra en la figura 4.26. Estos flujos (servidor a servidor y administrador de servidores) se pueden considerar críticos, además de los flujos de servidor a cliente. Con las capas adicionales de jerarquía en este modelo los servidores ahora pueden ser fuentes de datos o fregaderos (o ambos). Necesite más información acerca de las aplicaciones con el fin de determinar el estado de estos servidores. Este modelo es importante en que se reconozca al servidor y administrador de servidor para flujos. Un modelo de flujo de cliente – servidor jerárquico está indicado cuando múltiples aplicaciones, colaboraran y compartan información para realizar una tarea, o cuando varias aplicaciones cliente – servidor (o varias sesiones de la misma aplicación cliente – servidor) son administradas por una aplicación de nivel superior. Un sistema de soporte de operaciones (OSS) administrar varias aplicaciones back office pueden ser modelado a menudo de esta manera.

Figura 4.26 un modelo de flujo jerárquico de cliente – servidor

Corrientes críticas para este modelo son dependientes sobre el comportamiento de la aplicación. Si las aplicaciones son inherentemente cliente – servidor y los servidores están allí simplemente para apoyar varias sesiones, los flujos de cliente – servidor puede los flujos sólo críticos. Sin embargo, cuando los servidores se comunican entre ellos (por ejemplo, para actualizar una base de datos o compartir datos entre aplicaciones), entonces los flujos de servidor a servidor pueden ser críticos, posiblemente además de los flujos de cliente – servidor. Y de comunicación a un administrador (por ejemplo, para sincronizar información o proceso), entonces los flujos de administrador de servidores también pueden ser crítico. Hemos demostrado que el Internet ha evolucionado de un modelo de flujo de peer-to-peer temprano a un modelo de flujo de cliente – servidor con la aceptación de aplicaciones Web. Como ha crecido el tráfico de cliente – servidor, sin embargo, los servidores Web han replicado y distribuido a través de Internet, resultando en un incremento en los flujos de servidor a servidor. Esto se está haciendo para aumentar la efectividad del acceso a la Web, en parte por la difusión en múltiples dispositivos de acceso y en parte por la localización de dispositivos más cerca

a la porción de acceso de Internet, obviando todo o parte de la base. Como resultado, Internet está evolucionando a más de un modelo de flujo jerárquico de cliente – servidor. Servicios Web jerárquicas se muestran en la figura 4.27. En esta figura, las redes de distribución de contenido (CDN) y espejos (introducidos en el capítulo 1) se utilizan para migrar el contenido de la Web entre servidores y acceso local al contenido para los usuarios. En esta figura, los servidores pueden proporcionar la misma función o funciones diferentes. Por ejemplo, servidores de aplicaciones de tres capas basadas en Web pueden ejecutar aplicaciones y servicios Web en el mismo dispositivo, durante la ejecución de servicios de base de datos en otro dispositivo. En este caso los flujos entre servidores (aplicaciones Web y base de datos) son críticos para la operación.

Figura 4.27 Web Servicios modelados usando un modelo de flujo jerárquico de cliente – servidor

Este tipo de modelo de flujo puede verse también con el grupo de aplicaciones de visualización que se describe en el capítulo 2. Un ejemplo de esto es en la visualización de simulaciones científicas. Considerar la simulación de un problema de varias parte. Estos pueden encontrarse en la modelización del clima, análisis de flujo de fluidos, análisis estructural y otros. En el modelado del clima puede ser una simulación que consiste en múltiples partes, atmósfera, tierra y océano, como se muestra en la figura 4.28. Cada parte de la simulación en esta figura puede desarrollarse en un dispositivo de computación independiente, probablemente en diversas localizaciones (basado en donde se encuentran los diversos científicos). Puesto que cada componente afecta a los otros, en los límites entre atmósfera, tierra y océano, se deben pasar datos entre los servidores de computación/visualización para cada parte. Los flujos se vería en la figura 4.29. En esta figura, si las partes de

Figura 4.28 componentes de un clima modelado problema

Figura 4.29 un cliente – servidor jerárquico modelo para visualización científica

la simulación se están resolviendo en diferentes lugares, entonces los flujos de servidor a servidor pueden cruzar largo distancias (WAN), que afectan a ambas redes de área local y amplia.

4.6.4 Computación distribuida El modelo de flujo computación distribuida, que se muestra en la figura 4.30, es la más especializada de los modelos de flujo. Un modelo de computación distribuida de flujo puede tener el inverso de las características del modelo de flujo de cliente – servidor, o un híbrido de los modelos de flujo de peer-to-peer y cliente – servidor. En este modelo, los flujos pueden ser principalmente entre un gestor de tareas y sus dispositivos informáticos (como un modelo cliente – servidor) o entre dispositivos informáticos (como un modelo peer-to-peer). El tipo de modelo depende de cómo se hace la computación distribuida. Las características importantes de este modelo son los flujos pueden ser cliente – servidor que se invierten en la dirección, y que los dispositivos pueden tener requisitos de estricto cumplimiento. Podemos distinguir en el modelo de flujo de computación distribuida basado en la relación entre el administrador de tareas y los dispositivos de computación y lo que es la tarea. Esta relación puede resultar en los dispositivos informáticos se junta de cerca, donde hay frecuentes transferencias de información entre dispositivos, o combinados libremente, donde puede haber poco o ninguna transferencia de información entre dispositivos informáticos. Las tareas pueden variar desde tener una granularidad gruesa, donde cada tarea se dedica a un solo dispositivo informático, a tener una granularidad fina, donde una tarea se divide entre varios dispositivos y la computación se realiza al mismo tiempo.

Figura 4.30 A computación distribuida flujo modelo

Cuando la tarea tiene una granularidad gruesa y la relación de dispositivos informáticos está acoplada libremente, entonces el modelo de computación distribuida de flujo toma la forma de un clúster de computación o informática sistema de gestión de recursos, donde las tareas se asignan a cada computación dispositivo basado en la disponibilidad de recursos. Así, cada dispositivo informático se comunica con el servidor de clúster o administrador de recursos. Figura 4.31 muestra los flujos para obtener un ejemplo de un cluster de computación.

Figura 4,31 flujos para una computación Cluster

Los flujos en este tipo de modelo de flujo de computación distribuida son similares a las del modelo de flujo de cliente – servidor, donde las comunicaciones son principalmente entre cada cliente y el servidor. La diferencia aquí es que la dirección de los flujos no es necesariamente desde el servidor de computación a sus clientes. De hecho, el tamaño del archivo de inicialización de tarea (que es, en cierto sentido, una solicitud) enviado desde el servidor a cada dispositivo informático puede ser mucho más pequeño que el tamaño de los resultados del cómputo, que se envía desde el equipo informático en el servidor. En este modelo la direccionalidad del flujo es asimétrica, pero en la dirección opuesta desde el modelo de flujo de cliente – servidor. También, cada uno de los flujos entre los dispositivos de computación y su servidor es independiente de los otros flujos. Hay no hay sincronización entre flujos individuales. Los flujos críticos de este modelo son de los dispositivos de computación a su servidor. Puesto que los flujos para este modelo son

asimétricos, en la dirección hacia el servidor, el servidor actúa como un sumidero de datos, mientras que los dispositivos informáticos actúan como fuentes de datos. Cuando la tarea tiene una granularidad fina y la relación de nodo informático se junta de cerca, entonces el modelo de flujo de computación distribuida se comporta como un paralelo simplificado sistema de proceso donde cada tarea se subdivide, basado en el grado de paralelismo en la aplicación y la topología del problema, entre varios dispositivos informáticos. Estos dispositivos trabajan simultáneamente sobre el problema, intercambiar información con dispositivos de vecino y esperando (y esperando) información actualizan. El administrador de tareas configura los dispositivos de computación y comienza la tarea con un archivo de inicialización, como en la figura 4.32. Flujos en este tipo de modelo de flujo de computación distribuida pueden tener los más exigentes requisitos de rendimiento de cualquiera de los modelos. Puesto que pueden bloquear dispositivos informáticos (detener sus cómputos) mientras espera información de los dispositivos vecinos, el tiempo de transferencia de información entre dispositivos se vuelve crítico. Esto tiene un impacto directo en el retraso y la demora variación requisitos para la red que conecta los dispositivos. Aunque cada flujo individual tiene direccionalidad, colectivamente hay poca o ninguna direccionalidad general. Corrientes individuales en este modelo se pueden agrupar para indicar qué dispositivos de vecino un dispositivo informático se comunicará con para un problema dado o topología. Por ejemplo, puede configurarse un problema tal que un dispositivo informático le comunicará con uno, dos, cuatro o seis de sus vecinos más cercanos. Para este modelo, los flujos críticos son entre dispositivos informáticos. Cuando un dispositivo transferirá la misma información a varios vecinos simultáneamente, debe considerarse la multidifusión para optimizar el rendimiento de flujo.Hay no hay datos claros fuentes o sumideros para este modelo. El problema de la definición de modelos de clima que se muestra en la figura 4.28 podría

Priorización del flujo

Figura 4.32 flujos para computación paralela

también se considera con un modelo de flujo computación distribuida, dependiendo de la granularidad de tarea y el grado de acoplamiento en el sistema. Requerimientos de flujo variará entre el cluster de computación y modelos de sistema paralelo, dependiendo de los grados de acoplamiento y la granularidad en la tarea. Dependiendo de la aplicación y la cantidad de análisis que desea poner en este modelo, puede utilizar los modelos de sistema paralelo y cluster computing como son, o modificar la granularidad de la tarea y el grado de acoplamiento para satisfacer sus necesidades.

4.7 Priorización del flujo En el desarrollo y que describe los flujos de la red, puede encontrar útil para priorizar los flujos. Priorización del flujo significa clasificación de flujos basados en su importancia, que puede ser descrito de varias formas, dependiendo de su entorno. Los flujos pueden priorizarse según importancia, partiendo de las características indicadas en la figura 4.2. Algunas prioridades comunes incluyen: • Objetivos de la empresa y el impacto de un flujo en el negocio del cliente • Objetivos políticos • Uno o más de los requisitos de rendimiento del flujo (un subconjunto de capacidad, retraso,

RMA y calidad de servicio). • Requisitos de seguridad para cada flujo • El número de usuarios, aplicaciones o dispositivos que sirve a un flujo

El propósito de priorizar los flujos es comprender que fluye la mayoría de los recursos que fluye obtener recursos primera. Por lo general, el recurso principal es la financiación. Se trata de una forma totalmente nueva de mirar cómo asignar fondos para partes de la red. Por basar la asignación de recursos en los flujos, que son directamente representativos de los usuarios, sus aplicaciones y sus dispositivos, la arquitectura de red y el diseño resultante más exactamente representan requisitos de usuario, aplicación y dispositivo. Usted puede utilizar más de un parámetro para la asignación de prioridades, creando varios niveles de prioridad. Es común empezar por priorizar en base al número de usuarios que soporta un flujo y luego agregando otro parámetro, como un requisito de desempeño (p. ej., capacidad). Algunas prioridades de ejemplo se presentan en la figuras 4.33 y 4.34. En la figura 4.34 se priorizan los flujos por el número de usuarios que es compatible con el flujo. Esta información habría sido determinada de la especificación de requisitos y requisitos mapa, comparando dispositivo requerimientos, aplicación y usuario, y asignar flujos comunes. Para esta red hay un nivel de financiación ($750 K), que se distribuye a cada flujo basado en el número de usuarios compatibles.

Otro ejemplo prioriza los flujos basados en requisitos de desempeño, en este caso fiabilidad. Figura 4.35 se muestra un conjunto de flujos que han sido priorizadas de esta manera. En este ejemplo hay tres niveles de fiabilidad: 99.95% y 99.5% N/A Requisitos de desempeño

ID de flujo

Fiabilidad

Capacidad

Retardo de

Número de usuarios

F1

N/A

1.2 Mb/s

10 ms

1200

F2

99.5%

100 Kb/s

N/A

550

F3

99.5%

15 Kb/s

100 ms

100

CF1

99.95%

500 Kb/s

100 ms

1750

CF2

N/A

100 Kb/s

100 ms

2100

CF3

N/A

3 Mb/s

100 ms

50

Total presupuesto para proyecto de red: $750 K Figura 4.33 un ejemplo de flujo de información para la asignación de prioridades

La especificación de flujo

ID de flujo

Requisitos de desempeño

Número de usuarios

Presupuesto

Prioridad

Fiabilidad

Capacidad

Retardo de

CF2

N/A

100 Kb/s

100 ms

2100

$274 K

1

CF1

99.95%

500 Kb/s

100 ms

1750

$228 K

2

F1

N/A

1.2 Mb/s

10 ms

1200

$157 K

3

F2

99.5%

100 Kb/s

N/A

550

$72 K

4

F3

99.5%

15 Kb/s

100 ms

100

$13 K

5

CF3

N/A

3 Mb/s

100 ms

50

$6 K

6

Total presupuesto para proyecto de red: $750 K Figura 4.34 corrientes priorizadas por el número de usuarios servidos ID de flujo

Requisitos de desempeño

Número de usuarios

Presupuesto

Prioridad

Fiabilidad

Capacidad

Retardo de

CF1

99.95%

500 Kb/s

100 ms

1750

$375 K

1

F2

99.5%

100 Kb/s

N/A

550

$141 K

2

F3

99.5%

15 Kb/s

100 ms

100

$141 K

2

F1

N/A

1.2 Mb/s

10 ms

1200

$31 K

3

CF2

N/A

100 Kb/s

100 ms

2100

$31 K

3

CF3

N/A

3 Mb/s

100 ms

50

$31 K

3

Total presupuesto para proyecto de red: $750 K Figura 4.35 corrientes priorizadas por fiabilidad

(no aplicable). Son las asignaciones presupuestarias para cada nivel: nivel más alto, 1/2 de presupuesto; nivel medio, 3/8 de presupuesto; y más bajo nivel, 1/8 del presupuesto. Financiación puede aplicarse a esta lista de los flujos en una variedad de maneras. Puede ser aplicado basado en el nivel de confiabilidad, en cuyo caso todos los flujos con iguales niveles de fiabilidad Obtén cantidades iguales de los fondos. Esta asignación se puede refinar a continuación incluyendo otro parámetro, como los usuarios o aplicaciones que soporta. Cómo por flujo de fondos se refiere a compra de equipo se discute en el capítulo de diseño de red de este libro (capítulo 10).

4.8 La especificación de flujo Los resultados de identificar, definir y describir las corrientes se combinan en una especificación de flujo o flowspec. Una especificación de flujo muestra los flujos de una red, junto con sus requisitos de desempeño y niveles de prioridad (si existe). Especificaciones de flujo describen flujos requisitos mejor-esfuerzo, previsibles y garantizados, incluyendo críticos, velocidad crítica, en tiempo real, interactivo y bajo y alto rendimiento. La especificación de flujo combina requisitos de rendimiento para flujos compuestos, cuando hay múltiples requerimientos de aplicaciones dentro del flujo. También puede utilizarse para combinar los requisitos de todos los flujos en una sección de un camino. Hay mucha información, integrado en una especificación de flujo. Especificaciones de flujo pueden tomar uno de tres tipos: una sola pieza, o unitario; dos partes; o varias partes. Cada tipo de flowspec tiene un nivel de detalle, basada en si los flujos tienen requisitos de mejor esfuerzo, previsibles y garantizados. Un flowspec una parte describe los flujos que tienen solamente requisitos de mejor esfuerzo. Un flowspec dos partes describe los flujos que tienen requerimientos previsibles y pueden incluir flujos que tienen requerimientos de esfuerzo. Un flowspec varias parte describe los flujos que han garantizado requisitos y pueden incluir flujos que predecibles y mejor esfuerzo (Figura 4.36). Estas especificaciones de flujo varían en complejidad. Flowspecs una sola pieza y dos piezas puede ser relativamente sencilla, mientras que varias partes flowspecs puede ser bastante complejo. Flowspecs de dos partes son generalmente un buen equilibrio entre facilidad de desarrollo y cantidad de detalles. Muchas redes pueden representarse adecuadamente con un flowspec de una parte, cuando los requisitos de rendimiento y los flujos no son bien entendidos. Como integración a redes en el resto del sistema, sin embargo, flujos incorporará más fiabilidad y requisitos de demora, y las dos partes y varias partes flowspecs puede representar mejor la red. Este es el caso hoy de muchas redes. En el desarrollo del flowspec utilizamos la información en la especificación de requisitos y requisitos mapa como base de los flujos y aplicarán los métodos descritos en este capítulo para identificar y describir los flujos.

Tipo de especificación de flujo

Tipos de flujos

Descripción del funcionamiento

Una sola pieza

Compuesto y esfuerzo Individual

Capacidad sólo

Dos partes

Best-Effort y estocástico, individuales y compuestos

Confiabilidad, capacidad y retraso

Varias partes

Best-Effort, estocástica y garantizada, Individuales y compuestos

Confiabilidad, capacidad y retraso

Figura 4.36 descripciones de flujo especificaciones

La especificación de flujo

4.8.1 FLOWSPEC algoritmo Flowspecs se utilizan para combinar los requisitos de desempeño de múltiples aplicaciones para un flujo de compuestos o de varios flujos en una sección de un camino. El algoritmo flowspec es un mecanismo para combinar estos requisitos de desempeño (capacidad de demora y RMA) para los flujos de una manera tal como para describir el rendimiento compuesto óptimo para ese flujo o grupo de flujos. El flowspec algoritmo aplica a las siguientes reglas: 1. Mejor esfuerzo flujos consisten solamente en los requerimientos de capacidad; por lo tanto, solamente capacidades se utilizan en los cálculos de esfuerzo. 2. Para flujos con requisitos previsibles se utilizan todos los requisitos de rendimiento (capacidad de demora y RMA) en los cálculos. Requisitos de rendimiento se combinan para que cada característica con el fin de maximizar el rendimiento total de cada flujo. 3. Para los flujos garantizados requisitos enumeramos cada requisito individual (como un flujo individual), no los combina con otros requisitos. La primera condición se basa en la naturaleza del tráfico del mejor-esfuerzo, que es impredecible y poco confiable. Requisitos de RMA y retraso no pueden ser apoyados en un entorno de mejor esfuerzo. Lo mejor que puede esperarse es que los requerimientos de capacidad pueden ser apoyados a través de la planificación de capacidad (también conocido como ingeniería del tráfico) o por exceso de ingeniería la capacidad de la red para apoyar estos requisitos. La segunda condición está en el corazón del flowspec — que para cada característica de funcionamiento, capacidad, retraso y RMA, los requisitos se combinan para maximizar el rendimiento del flujo o grupo de flujos. Cómo se combinan los requisitos para maximizar el rendimiento se discute más adelante en este capítulo. La tercera condición se basa en la naturaleza de los requisitos de garantía. Flujos con tales requisitos deben ser soporte end-to-end, sus necesidades se mantienen separadas por lo que podemos identificar en la arquitectura de red y el diseño.

Cuando se desarrolla un flowspec de una sola pieza (para flujos con requerimientos de mejor esfuerzo), luego se combinan las capacidades de los flujos. No debe haber requisitos de RMA o retraso de estos flujos. Capacidades se agregan juntos, formando una capacidad total de esfuerzo CBE, como se muestra en la figura 4,37. Un flowspec dos partes se basa en un flowspec de una parte, agregar capacidades predecibles, retraso y RMA. Cuando se desarrolla un flowspec de dos partes (para flujos con mejor esfuerzo y predecible), los flujos del mejor-esfuerzo se combinan en

4,37 figura una especificación de flujo de una pieza

al igual que para el flowspec de una sola pieza. Para los requerimientos previsibles, las capacidades se suman como con los flujos de mejor esfuerzo, para que el flowspec tiene una capacidad total para mejor esfuerzo fluye CBE y otra capacidad para flujos predecibles CP. Para la demora y requisitos de RMA para flujos predecibles, el objetivo es maximizar cada requisito. Retraso, la demora mínima (es decir, el retraso de la highestperformance) de todos los requisitos de retardo se toma como el previsible retraso DP por el flowspec y el RMA máximo (es decir, la más alta performance RMA) de todos los requisitos de RMA se toma como la previsible RMA RP por el flowspec. Figura 4.38 ilustra esto para un flowspec de dos partes. Un flowspec varias parte es la más compleja de la flowspecs, partiendo de un flowspec dos partes para añadir requisitos garantizados. Capacidad de esfuerzo, junto con capacidad predecible retraso y RMA, se genera de la misma manera en cuanto a un flowspec de dos partes, y cada juego me de rendimiento garantizado requisitos se añade individualmente (como C R me D) a flowspec, como se muestra en la figura 4.39. Sistemas de garantía de rendimiento requisitos Ci R D figuran individualmente en el flowspec para demostrar que se apoya como las necesidades individuales y no agrupados con otros requisitos. Esto es necesario para poder financiar cada requisito garantizada en toda la red.

Figura 4.38 una especificación de flujo de dos partes

me

Figura 4.39 una especificación de flujo concatenados

4.8.2 Servicio de planificación y capacidad de Capacidad y planes de servicio se escriben las descripciones de la performance de la red requerida para los flujos descritos en el flowspec. Un plan de capacidad describe el rendimiento de la red en términos de capacidad solamente. Se utiliza en conjunción con un flowspec de una sola pieza. Un plan de servicio describe el rendimiento de la red en términos de conjuntos de capacidad, demoras y RMA. Se utiliza en conjunto con dos partes y varias parte de la flowspecs. Mientras un flowspec listas de flujos y combina sus requerimientos de performance, capacidad y planes de servicio describen lo que pueden ser necesarias para tales necesidades. Como vemos en

el capítulo sobre el rendimiento (capítulo 8), hay muchos mecanismos que podemos elegir para soportar los requerimientos de rendimiento de la red.

4.9 Ejemplo de aplicación de análisis de flujo Ahora traemos los conceptos de análisis de flujo juntos para una red de ejemplo, en este caso una red para apoyar la administración del almacenamiento y de computación. Para este proyecto de red los dispositivos de computación y almacenamiento de información ya existen en varios edificios en un campus. Los edificios y los dispositivos que va a utilizar esta red para la gestión informática y almacenamiento se muestran en la figura 4.40. Desde el proceso de análisis de requisitos, hemos podido determinar que existen cuatro tipos de corrientes para esta red: Tipo 1: fluye entre los dispositivos de computación de alto rendimiento. Hay servidores de cálculo que son los dispositivos de alto rendimiento para esta red. El primer tipo de flujo consiste en flujos de tráfico entre estos dispositivos. Los flujos son a veces (aproximadamente

Figura 4.40 edificio y lugares de dispositivo para el ejemplo

10% del tiempo) sincronizado entre pares de dispositivos. En otras ocasiones estos dispositivos pueden extraer datos desde el almacén de datos locales de otro dispositivo de computación, desde el servidor de almacenamiento de información en el edificio principal de ingeniería, o solicitar una tarea de administración informática o datos de un dispositivo. Más las tareas se controlan desde la ingeniería principal. Tipo 2: migración de datos de computación al almacenamiento principal ingeniería. Estos flujos pueden ser desde cada servidor de cálculo como su tarea se ha completado; desde el almacén de datos local en cada servidor de cálculo en un momento específico; o desde el servidor de cálculo en ingeniería de principal en la realización de una tarea (varios servidor) combinada. Tipo 3: migración de datos a servidor externo. Final de conjuntos de datos o extractos finales de conjuntos de datos, son empujados desde el servidor principal ingeniería de almacenamiento a un servidor de almacenamiento de información en un edificio donde se administra el acceso externo

(Internet). Datos en este servidor de acceso externo se utilizan para alimentar otros campus y para archiving de datos (off-site) remoto. Tipo 4: archiving de datos y acceso a Internet. Se trata de flujos desde el servidor de acceso externo a los usuarios de Internet, así como los flujos a los servidores de archivo fuera del sitio. Este tipo de flujo se agrega a nuestro mapa, como se muestra en la figura 4.41. De las conversaciones con varios usuarios de estas aplicaciones, nos enteramos que flujo generalmente se ejecuta en este orden: tipo 1 tipo 2 tipo 3 – tipo 4. Para flujo tipo 1, un servidor de cálculo principal ingeniería puede actuar como un servidor para los servidores de cálculo en edificios A, C y para obtener datos de los servidores de almacenamiento de información principal ingeniero. Esto sigue un modelo de flujo jerárquico de cliente – servidor. Calcular los servidores de edificios

Figura 4.41 el mapa con los tipos de flujo añadido

A – C y principal ingeniería también pueden actuar como pares sincronizados, utilizando un modelo de flujo de distributedcomputing. De las conversaciones con usuarios de ingeniería que se encontró que la aplicación informática funciona en batch o en modo interactivo, de unos 10 minutos a varias horas, generando archivos de tamaños que van de 1 a 2MB (sincronización o sincronizar archivos), (de 10 a 100MB actualizaciones interactivas) y 100 MB más 1 GB para la final los conjuntos de datos. Interactividad de la aplicación informática es necesario para orientar o dirigir el cómputo. Esto requiere la sincronización del orden de HRT (100ms) y las actualizaciones del orden de 1 segundo. Usuarios esperan a tener hasta dos tareas que se ejecutan concurrentemente. Para flujo tipo 2, los datos se almacenan en los servidores de almacenamiento de información principal ingeniero. Los datos pueden ser de versiones interactivas, conjuntos de datos finales y extractos (subconjuntos seleccionados del conjunto final de datos). Datos también migran de tiendas locales en cada equipo servidor, generalmente cada pocas horas.

Para flujo tipo 3, sistemas completos de datos, así como extractos de los conjuntos de datos se migran al servidor de acceso externo. Los extractos son aproximadamente el 80% del tamaño de un conjunto completo de datos. Conjuntos de datos se migran cada hora. Para flujo tipo 4, usuarios de otros recintos, a través de Internet, a los datos. Conjuntos de datos se archivan en una instalación fuera del sitio. Se espera que el sistema de apoyo la descarga de un conjunto de datos completo final en pocos minutos. Envolvente del rendimiento de análisis de requerimientos Características de flujo tipo 1. Flujos de tipo 1 incluyen el paso frecuente de 1 – 2MB sincronizar archivos con demoras del orden de HRT, 10-100 MB los archivos de actualización del orden de 1 segundo y final los conjuntos de datos de 500 MB – 1 GB del orden de minutos a horas, con hasta dos tareas que se ejecutan concurrentemente. De esta información se puede estimar un rango de capacidad de performance de estos flujos. Cada uno de estos flujos se multiplica por 2 para concurrencia. Sincronizar archivos: (1 a 2MB)(8b/B)(2 concurrent tasks)/10−1 s = 160 a 320 Mb/s Archivos de actualización: (10 a 100MB)(8b/B)(2 concurrent tasks)/1s = 160 Mb/s a 1,6 Gb/s Final de conjuntos de datos: (500 a 1000MB)(8b/B)(2 concurrent tasks)/102 a 10 s de4 = 800 Kb/s a 160 Mb/s Características de flujo tipo 2. Estos flujos incluyen migrantes versiones (empujando), conjuntos de datos finales y extractos. Las características de retardo de estos flujos son mucho lessstrictthanforthecomputingfunction, withdelaysrangingfrom10to104 segundos. Actualización de archivos: ()(8b/B)/10 de 10 a 100MB a 10 s de4 = 8 Kb/s hasta 80 Mb/s Conjuntos de datos finales: igual que para flujo tipo 1 La envolvente de funcionamiento para la final los conjuntos de datos, actualizaciones y archivos de sincronización se muestra en la figura 4.42.

Figura 4.42 la envolvente de desempeño para el ejemplo

Modelos de flujo Para flujo tipo 1 entre los servidores computacionales y los ingeniería principal servidores de almacenamiento, flujos pueden seguir computación distribuida y modelos de flujo informático cliente – servidor jerárquica, como se muestra en la figura 4.43. En el modelo de computación distribuida, de que cada dispositivo puede actuar como un origen de datos y fregadero y datos transferencia se sincroniza entre dispositivos a unos 100ms. En el modelo cliente – servidor jerárquico, conjuntos de datos pueden fluir desde el servidor de almacenamiento a los servidores de cálculo principal ingeniero, que luego pasan hacia abajo para calcular servidores en edificios A – C. No hay ninguna sincronización para este modelo. Flujo tipo 2 consiste en datos empuja desde cada servidor de cálculo para el servidor de almacenamiento principal ingeniero. Cada servidor de cálculo es un origen de datos, mientras que

el servidor de almacenamiento de información principal ingeniería es un sumidero de datos (Figura 4.44). Para flujo tipo 3, los servidores de almacenamiento de información principal ingeniería son fuentes de datos y el servidor de acceso externo es un sumidero de datos (Figura 4.45). Para flujo tipo 4 un modelo de flujo de cliente – servidor existe entre los usuarios externos de los datos fuera del sitio como archivo y el servidor de acceso externo (Figura 4.46).

Figura 4.43 modelos de flujo para flujo tipo 1

Modelo de flujo de la figura 4.46 para flujo tipo 4

Figura 4.47 mapa un flujo para el ejemplo

Mapa de flujo Figura 4.47 es un ejemplo de un mapa de flujo que describe los flujos entre los edificios. Tenga en cuenta que todos los dispositivos han sido retirados de este mapa. Esto se hace a menudo para redes más grandes, como el número de dispositivos en el mapa puede ser difícil de manejar. También, se ha añadido un punto de agregación de flujo entre edificios A, C y principal ingeniería. Esto se hace para ver los requisitos de rendimiento agregado en principal Ingeniería (flujo F4). De este mapa de flujo, flujos F1, F2 y F3 tienen los mismos requisitos de desempeño, que consiste en tipos de flujo 1 y 2. Flujo F4 es un agregado de los flujos F1, F2 y F3 (flujo de tipos 1 y 2). F5 de flujo consiste en flujo tipo 3, y F6 y F7 los flujos son corrientes de flujo tipo 4. A continuación los requisitos de rendimiento de cada uno de los tipos de flujo se combinan y aplican a flujos F1 a F7, como se muestra en la figura 4.48. Requisitos de desempeño ID de flujo Capacidad (Mb/s)

Retardo (ms)

F1: Flujo tipo 1 Sincronización de archivos Archivos de actualización Archivos finales Resultados de flujo de tipo 1

320

100

1600

1000

160

105

1600

100

F1: Flujo tipo 2 Archivos de actualización

80

104

Archivos finales

160

105

Resultados de flujo de tipo 2

160

104

Resultados de la F1

1760

100

1760

100

1760

100

1600

100

Resultados de la F2

Resultado para F3

F4: Flujo tipo 1

F4: Flujo tipo 2 Archivos de actualización

320

104

Archivos finales

640

105

Resultados de flujo de tipo 2

640

104

Resultados de F4

2240

100

Resultados de F5

16

103

Resultados de F6

80

102

Resultados de F7

16

103

Figura 4.48 requisitos de rendimiento para flujos de

Conclusiones

Requisitos de funcionamiento de la figura 4.49 añadidos al mapa de flujo

Figura 4.50 dos partes Flowspec para cada flujo con rendimiento Perfil P1

Cuando estos requisitos de desempeño se agregan al mapa de flujo de la figura 4.47, obtenemos la figura 4.49. Se generaron dos perfiles de desempeño para varios flujos: P1 para flujos F1, F2 y F3; y P2 para flujos F5 y F7. Un flowspec dos partes para cada flujo que tiene un perfil de desempeño de P1 (F1, F2 y F3) se vería como la figura 4.50.

4.10 Conclusions Análisis de flujo de toma una perspectiva end-to-end de requisitos de desempeño de la red, combinando capacidad, demora y requisitos de RMA en una especificación que se utiliza como entrada a la red de arquitectura y diseño, para evaluar y ayudar a seleccionar tecnologías y estrategias de diversidad de la red. En la construcción de la especificación de flujo utilizamos varias técnicas, incluyendo modelos de flujo y fregaderos y fuentes de datos identificar y determinar los flujos individuales y compuestos, así como flujos críticos. Análisis de flujo es la parte final del proceso de análisis. Comenzamos este proceso reuniendo, derivados, gestión y seguimiento de requerimientos para la red de usuarios, aplicaciones, dispositivos y redes que formarán parte de la red planificada. En el desarrollo de los requisitos de la red, se consideraron requisitos de desempeño (en términos de capacidad, demoras y RMA) y las muchas maneras de clasificar los requisitos para los usuarios, aplicaciones, dispositivos y redes. Esta información, junto con las condiciones iniciales, las definiciones de problema y objetivos, fue recogida en la especificación de requisitos y trazado en un mapa de necesidades. Requisitos de desempeño, de forma por aplicación o agrupados por usuario, aplicación, dispositivo o red, se agregan a la direccionalidad, jerarquía y diversidad de los flujos de tráfico para caracterizarlos. Algunas herramientas, tales como fuentes de datos y fregaderos, modelos de flujo y puntos de agregación de flujo, se pueden utilizar para ayudarnos a determinar que los flujos son importantes en una red y donde los flujos son probables ocurrir. Se les anima a desarrollar otras herramientas para ayudar en el análisis de flujos, o modificarlas presentadas en este libro para sus necesidades. Mientras que el análisis de flujo se presenta aquí como parte del proceso general de análisis, en preparación para el arquitecto y diseñar una red, debe señalarse que el análisis de flujo se puede realizar en cualquier red, sin importar de qué estado. Note que durante todo el proceso de análisis de flujo, no tecnologías de red, topologías o infraestructuras subyacentes se muestra o mencionadas. Análisis de flujo nos permite movimiento de tráfico separado y requisitos de funcionamiento de una red existente, que nos da la libertad para determinar qué flujos deben parecerse a cuando la red no restringir el movimiento o el rendimiento. Si usted analiza las corrientes en una red existente (sin importar si o no están desarrollando una nueva red o mejorar la red existente), los resultados de este análisis indicará si la red existente necesita ser modificado para adaptarse a los flujos de tráfico.

Ahora que ya tenemos una idea de qué esperar de la red en términos de requisitos y corrientes, estamos preparados para comenzar el proceso de arquitectura de la red.

4.11 Exercises 1. Mostrar flujos para cada conjunto de dispositivos y aplicaciones abajo. Etiqueta cada una como un flujo unidireccional o bidireccional. a. Aplicación cliente – servidor: aguas abajo (de servidor a cliente): 1,2 Mb/s (del cliente al servidor); capacidad: capacidad de 15 Kb/s. b. Streaming video (UDP) de servidor de video a la PC del abonado: capacidad de 300Kb/s, demora de 40ms (unidireccional). Ejercicios

c. Descarga de páginas de la Web: aguas abajo: capacidad de 250Kb/s y 5 segundo retardo; aguas arriba: capacidad de 100Kb/s. d. Procesamiento de puntos de venta máquina al servidor de transacciones: río arriba (de máquina de la posición al servidor): capacidad de 30Kb/s, retardo de ida y vuelta de 100ms; abajo: capacidad de 50Kb/s. 2. Dispositivos pueden actuar como fuentes y sumideros, dependiendo de la aplicación y el flujo. Cuál de los siguientes dispositivos (para las aplicaciones dadas) son datos hunde? ¿Fuentes de datos? a. Un dispositivo de almacenamiento recepción de streaming de vídeo desde una cámara b. Una unidad de edición video, utilizando el vídeo desde el dispositivo de almacenamiento en (a) c. Web de un servidor y sus clientes d. Una granja de discos de almacenamiento de información 3. Que se aplican modelos de flujo para cada conjunto de flujos que se describen a continuación? a. Usuarios de Internet acceder al mismo servidor Web b. 40 estaciones de trabajo de procesamiento por lotes puestos de trabajo durante la noche, a cargo de un mainframe central c. Uso de correo electrónico a través de Internet d. Una aplicación de procesamiento de transacciones, que autoriza las transacciones de tarjeta de crédito entre tiendas de la empresa y su sede 4. Para cada uno de los ejemplos en el ejercicio 3, da las direcciones más probables para los flujos descritos por cada modelo de flujo. 5. Desarrollar un modelo de flujo para flujos de real-time/cerca de tiempo real. ¿Cómo se caracterizan los flujos para este modelo? ¿Cuáles son los fregaderos y fuentes de datos probablemente? El modelo se aplica a una aplicación de videoconferencia. 6. Está desarrollando una red en línea de procesamiento de transacciones de una compañía (por ejemplo, una venta por menor red de ventas) de la aplicación (OLTP). Su sistema actual es un mainframe que tiene varios terminales conectados a él, ya sea directamente o a través de un servidor de terminal server, como en la figura 4.51. Se está moviendo a una red jerárquica de cliente – servidor, donde será

Figura 4.51 un entorno de Mainframe para una aplicación OLTP

Figura 4.52 un ambiente jerárquico cliente – servidor para la aplicación de un OLTP

múltiples servidores de base de datos regional, cada uno actuando de manera cliente – servidor y actualización de otras regiones a través de un gestor de base de datos, como en la figura 4.52. a. Mostrar las fuentes de datos probables y sumideros para ambos entornos. b. ¿Cómo se migran desde el entorno de mainframe al ambiente cliente – servidor jerárquico modifique los flujos de tráfico en la red? c. ¿De qué manera el entorno de red mejora los flujos de tráfico? d. ¿Cuáles son algunas de las posibles ventajas y desventajas entre los dos entornos, por ejemplo, en seguridad, administración y funcionamiento?

Esta página dejada intencionadamente en blanco

CAPÍTULO CONTENIDO 5.1 Objectives 5.1.1 Preparation 5.2 Background 5.2.1 Arquitectura y diseño 5.3 Arquitecturas de componentes 5.3.1 Arquitectura de componentes de direccionamiento/enrutamiento 5.3.2 Arquitectura de componentes de gestión de red 5.3.3 Arquitectura de componentes de rendimiento 5.3.4 Arquitectura de componentes de seguridad

5.3.5 Optimización de las arquitecturas de componente 5.4 Arquitectura de referencia 5.4.1 Relaciones externas 5.4.2 Optimización de la arquitectura de referencia 5.5 Modelos arquitectónicos 5.5.1 Modelos topológicos 5.5.2 Modelos basados en el flujo 5.5.3 Modelos funcionales

5.5.4

Utilizando los modelos arquitectónicos

5.6 Sistemas y arquitecturas de red 5.7 Conclusions 5.8 Exercises

210

5 Arquitectura de red Arquitectura de red es la estructura de alto nivel, end-to-end de la red. Esto incluye las relaciones dentro y entre los principales componentes de la arquitectura de la red, como el direccionamiento y enrutamiento, gestión de red, rendimiento y seguridad. Determinar la arquitectura de red es la siguiente parte del proceso de desarrollo de nuestra red y es, como veremos, la clave en la integración de los requisitos y flujos en la estructura de una red.

5.1 Objectives En este capítulo usted aprenderá acerca de la arquitectura de red: lo que está dentro de la arquitectura de una red y cómo desarrollar esta arquitectura. Discutimos el concepto de las relaciones dentro y entre los componentes de la arquitectura. Usted aprenderá los factores que conforman estas relaciones y cómo se aplican a cada componente arquitectónico. También presentamos varios modelos para su uso como punto de partida en el desarrollo de su arquitectura de red. Este capítulo presenta varios conceptos de arquitectura de la red, algunas de las cuales pueden ser nuevos para usted. Además, muchos términos para direccionamiento y enrutamiento, rendimiento, administración de redes y seguridad se presentan en este capítulo pero se detallarán en los capítulos 6 al 9.

5.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con los conceptos básicos y mecanismos de funcionamiento (por ejemplo, QoS), seguridad y privacidad, administración de redes, enrutamiento y direccionamiento.

5.2 Background ¿Qué es arquitectura de red? En general, la arquitectura es el arte y la ciencia de diseñar y construir o la que trata de la disciplina con los principios de diseño 211

y de construcción. Esto se aplica a la arquitectura de red, hay arte y ciencia en el diseño y construcción de una red. Una definición más específica para arquitectura de red es una comprensión de las relaciones entre los componentes (arquitectónicos) de la red. Arquitectura de red también guía el diseño técnico de la red, a través de la aplicación de los principios de diseño

de alto nivel. Aplicación de estos principios de diseño de alto nivel a los bloques de construcción de la red nos ayuda a desarrollar la estructura y la función general. Discutimos la naturaleza de estas relaciones, los principios de diseño y bloques de construcción en este capítulo. Es esencial para el éxito de la arquitectura de red definir los bloques de construcción. Es intuitivo considerar éstos que las entidades físicas (routers, switches, multiplexores, servidores, etc.) en la red, especialmente puesto que son fácilmente asignados a tecnologías de red y comprados de proveedores. Sin embargo, esta visión común de la arquitectura de red limita las funciones de una red (direccionamiento/routing, seguridad, gestión de red, rendimiento) para operar dentro de esta estructura física. Esto obliga a funciones en configuraciones subóptimas, como sucede cuando una función de red disminuye o niega la eficacia de otro. Por ejemplo, co-ubicada con routers o switches, sin consideración de enrutamiento o de funcionamiento, los mecanismos de seguridad pueden afectar seriamente a las funciones. Un enfoque diferente es definir los bloques de construcción de la red como funcional en lugar de entidades físicas. De esta manera, el conjunto de principios de alto nivel de diseño que constituyen la arquitectura de red se aplica a cómo la red funciona y funciona. Esto tiene varias ventajas sobre el enfoque físico. Funciones de red están estrechamente acopladas a usuarios, sus aplicaciones y sus dispositivos. Esto permite requisitos de usuario ser representados directamente en la arquitectura de red. De hecho, el éxito de una red puede definirse bien como usuario, aplicación y los requisitos de dispositivo son compatibles a través de estas funciones. Además, funciones de red, como usuario, aplicaciones y requisitos del dispositivo, a menudo tienen una base común en flujos de tráfico. Como parte de la arquitectura de red, la caracterización de los flujos de tráfico puede indicar cuándo y dónde funciones de red funcionarán en los flujos de común y así pueden afectar uno con el otro y la eficacia global de la red. Centrándose en funciones de la arquitectura de red, se entienden mejor estas interacciones. Interacciones, dentro de una función y entre funciones, sirven para optimizar la arquitectura de red. En este capítulo que discutiremos cómo describir, entender y optimizar las funciones de una red, sus interacciones dentro de la red y cómo se pueden combinar significativo para esa red. En este enfoque cada función de la red es desarrollado y optimizado como su propia arquitectura de componentes. Arquitecturas de componentes Fondo

luego se combinan en una arquitectura de referencia, mediante el análisis y optimización de las interacciones entre los componentes. Desde este enfoque se centra en funciones de red y sus interacciones, es escalable a redes más grandes. Este proceso puede aplicar a toda la red, parte de una red, o centrado en una función en particular. Proporciona un conjunto de pautas arquitectónicas que pueden utilizarse para formular el diseño técnico de una red, consistente con la filosofía de arquitectura de Internet.

5.2.1 Arquitectura y diseño Es fácil confundir la arquitectura y el diseño. Son similares en muchas formas y diseños son a menudo versiones más detalladas de la arquitectura. Sin embargo, hay maneras en que difieren. Figura 5.1 compara algunas de las similitudes y diferencias entre la arquitectura y diseño. Algunas de estas diferencias reflejan el concepto que el diseño es más detallado. Por ejemplo, considerando que el ámbito de la arquitectura es típicamente amplio, diseños tienden a centrarse más. Arquitectura de red muestra una vista de alto nivel de la red, incluyendo localizaciones de componentes importantes o importantes, mientras que un diseño de red con información detallada sobre cada porción de la red o se centra en una sección particular de la red (por ejemplo, almacenamiento, servidores, Computing). El diseño se centra en las partes seleccionadas de la red, aumenta el nivel de detalle sobre esa parte. Arquitectura y diseño son similares de una manera importante: ambos intentan resolver problemas multidimensionales basados en los resultados del proceso de análisis de red. Figura 5.2 muestra que un espacio de solución puede ser conformado por muchas variables (por ejemplo, rendimiento, seguridad y administración de redes) y esa red

Diseño de la arquitectura

Figura 5.1 comparaciones entre la arquitectura y diseño

Figura 5.2 arquitectura y soluciones de diseño son multidimensionales

soluciones de arquitectura se basan en las relaciones entre estas variables. Discutimos estas relaciones durante todo el proceso de la arquitectura. En cuanto a lo que se describe, sin embargo, la arquitectura puede diferir substancialmente el diseño. Arquitectura de red describe las relaciones, mientras que un diseño especifica generalmente tecnologías, protocolos y dispositivos de red. Así que podemos empezar a ver cómo el complemento de la arquitectura y el diseño, para él es importante comprender cómo diversos componentes de la red trabajarán juntos antes de realmente especificar el equipo a implementar. Otra forma de arquitectura puede variar desde el diseño es en la necesidad de información de ubicación. Mientras que hay algunas partes de la arquitectura donde la ubicación es importante (por ejemplo, externa interfaces, ubicaciones de los dispositivos existentes y aplicaciones), las relaciones entre los componentes suelen ser independientes de la ubicación. De hecho, insertando información sobre la ubicación de la arquitectura de red puede ser vinculantes. Para un diseño de red, sin embargo, información de ubicación es importante. (En el diseño hay una cantidad suficiente de detalle que lugares juegan una parte importante de la toma de decisiones). Buen diseño es un proceso por el cual se conceptualiza un sistema extremadamente complejo y no lineal. Incluso el diseñador más experimentado de la red debe primero conceptualizar una imagen grande y luego desarrollar los diseños detallados de los componentes. La arquitectura de red representa esa imagen grande y sólo se pueden desarrollar mediante la creación de un

ambiente que equilibra los requerimientos de los clientes con las capacidades de las tecnologías de red y el personal que ejecutará y mantener el sistema.

La arquitectura de red no sólo es necesaria un diseño sólido; también es esencial para el sostenimiento de las prestaciones requeridas en el tiempo. Red personal debe comprender el panorama y entenderlo para poder hacer la red realice como diseñado. Para tener éxito, desarrollo de la arquitectura debe ser abordado de manera sistemática. Diseño y arquitectura de la red pobre refleja la personalidad de un "mago" que abre su bolsa de trucos de red y tira un par de ellos. Desarrollo de arquitectura y diseño de redes ya no es lo suficientemente simple como para trucos para trabajar; debe realizarse de forma sistemática y reproducible. Incluso si un red compleja arquitectura/diseño es engañado en existencia, no puede mantenerse. Los clientes inteligentes han pasado más allá de la etapa donde se contratan a un "mago" a la magia. Han sido quemados (o escuchado acerca de ser quemados) por la imprevisibilidad de este comportamiento. Ahora que los servicios de red son esenciales para el negocio, previsible, confiable, rendimiento de alta calidad es lo que los clientes están buscando.

5.3 Arquitecturas de componentes Arquitectura de componentes es una descripción de cómo y dónde se aplica cada función de una red dentro de esa red. Consiste en un conjunto de mecanismos (hardware y software) por que esa función se aplica a la red, donde cada mecanismo puede ser aplicado y un conjunto de relaciones internas entre estos mecanismos. Cada función de una red representa una capacidad importante de esa red. Este libro explora cuatro funciones que son importantes capacidades de redes: direccionamiento de enrutamiento, administración de redes, rendimiento y seguridad. Otras funciones generales, tales como infraestructura y almacenamiento, también podrían ser desarrollados como arquitecturas de componentes. Y sin duda puede haber funciones específicas a cada red que desee desarrollar. Los mecanismos son hardware y software que ayudan a una red para lograr la capacidad de cada uno. Algunos mecanismos de ejemplo en la figura 5.3 se muestran y se examinan en detalle en los capítulos 6 al 9 en las arquitecturas de componente. Relaciones internas consisten en las interacciones (compensaciones, dependencias y limitaciones), protocolos y mensajes entre los mecanismos y se utilizan para optimizar cada función dentro de la red. Trade-offs son puntos de decisión en el desarrollo de la arquitectura de cada componente. Se utilizan para priorizar y decidir qué mecanismos deben aplicarse. Las dependencias se producen cuando un mecanismo se basa en otro mecanismo para su funcionamiento. Limitaciones son restricciones que uno de los mecanismos Ejemplo de subconjunto de Función

Descripción de la capacidad de

mecanismos utilizados para lograr la capacidad de • Abordar: maneras de asignar y

Abordar/enrutamiento

Provee conectividad robusta y flexible entre los dispositivos

agregar espacio de direcciones • Routing: Routers, protocolos de enrutamiento, formas para manipular flujos de enrutamiento

• Protocolos de gestión de red Administración de redes

Proporciona monitoreo, configuración y solución de problemas de la red

• Dispositivos de administración de red • Maneras de configurar la gestión de la red en la red

Proporciona recursos de la red para Rendimiento

Seguridad

soportar los requerimientos de

• Calidad de servicio • Acuerdos de nivel de servicio

capacidad, retraso, RMA

• Políticas de

Restringe el acceso no autorizado, uso

• Cortafuegos

y visibilidad dentro de la red para reducir la amenaza y los efectos de los ataques

• Procedimientos y políticas de seguridad • Filtros y listas de control de acceso

Figura 5.3 funciones, capacidades y mecanismos de

lugares en otro. Estas características de relación ayudan a describir los comportamientos de los mecanismos dentro de una arquitectura de componentes, así como el comportamiento global de la misma función. Desarrollo de una arquitectura de componentes consiste en determinar los mecanismos que integran cada componente, el funcionamiento de cada mecanismo, así como funcionamiento de ese componente en su conjunto. Por ejemplo, considere algunos de los mecanismos de actuación: calidad de servicio (QoS), acuerdos de nivel de servicio (SLAs) y políticas. Para determinar funcionamiento funcionamiento de una red, debemos determinar el funcionamiento de cada mecanismo y cómo trabajan juntos para ofrecer un rendimiento del sistema y red. En Figura 5.4 QoS se aplica en cada dispositivo de red para el control de sus recursos en apoyo a las políticas y los SLAs, SLAs atan los suscriptores a los niveles de servicio y políticas (situadas generalmente en una o más bases de datos en la red) proporcionan un marco de alto nivel para el servicio niveles, SLAs y QoS. Las interacciones dentro de un componente se basan en lo que requieren de mecanismos para comunicar y operar con los demás. Utilizando el ejemplo de funcionamiento en la figura 5.4 se determinaría si hay cualquier flujo de información entre el QoS, SLA y políticas. Si existen dichos flujos (y suelen hacerlo), entonces sería determinar dónde y cómo estos flujos se producen. Esto es importante saber, para cuando estamos desarrollando una arquitectura para un componente, sus comunicaciones

Figura 5.4 ejemplos de mecanismos de funcionamiento en una red

Figura 5.5 las interacciones entre los mecanismos de funcionamiento

requisitos dentro de ese componente ayudará a conducir a que la arquitectura. Figura 5.5 muestra un ejemplo de donde las interacciones ocurren entre los mecanismos de funcionamiento. Ventajas y desventajas son puntos de decisión en el desarrollo de cada componente, decisiones para priorizar y elegir entre funciones y características de cada mecanismo y para optimizar la arquitectura de cada componente. A menudo hay varias ventajas y desventajas dentro de un componente, y gran parte de la refinación de la arquitectura de red ocurre aquí. Por ejemplo, un compromiso común en la gestión de red implica la elección entre centralización y distribución de capacidades de gestión. Como se mencionó en el capítulo 1, ventajas y desventajas son fundamentales para la arquitectura de la red en cuanto a diseño de red. Por lo tanto pasaremos mucho tiempo en ventajas y desventajas en este capítulo y en el resto del libro. Las dependencias son requisitos que describen cómo un mecanismo depende de uno o más mecanismos para que funcione. Determinar tales dependencias nos ayuda a decidir cuando las compensaciones son aceptables o inaceptables. Por ejemplo, hay dependencias entre el direccionamiento y enrutamiento, direccionamiento se realiza como la función de enrutamiento correcta depende en forma interna y externa. Las restricciones son un conjunto de restricciones dentro de la arquitectura de cada componente. Por ejemplo, SLAs están limitados por el tipo y la colocación de QoS en la red. Estas limitaciones son útiles en la determinación de los límites mediante la cual cada componente opera. Aunque las funciones descritas en este capítulo se limitan a abordar/enrutamiento, gestión de red, rendimiento y seguridad, hay a menudo otras funciones, tales como almacenamiento en red informática y servicios de aplicación, que puede ser descrito también por este enfoque de la arquitectura de componentes. Funciones pueden ser definidas por usted y pueden ser específicas a la red que está trabajando. Experiencia ha demostrado abordar/routing, seguridad, rendimiento y administración de la red son comunes en la mayoría de las redes. Mediante el desarrollo de las relaciones entre estas funciones, empezamos a desarrollar una visión de alto nivel, end-to-end de la red y sistema. Desarrollo de arquitecturas de componentes requiere entrados, en cuanto a sistemas de usuario, aplicación y requisitos del dispositivo, los flujos de tráfico Estimado y arquitectónicos objetivos definidos para cada red individual. Por ejemplo, usuario, aplicación y requisitos de rendimiento y seguridad del dispositivo se utilizan como criterios para evaluar los mecanismos para el

funcionamiento y las arquitecturas de componente de seguridad. Esta entrada forma una base común para todas las funciones de red, de los cuales se desarrollan todas las arquitecturas de componente. Figura 5.6 ilustra arquitecturas de componentes, requerimientos, flujos, y objetivos están todos entretejidos a través de la arquitectura de referencia.

Figura 5.6 arquitecturas de componentes y la arquitectura de referencia se derivan de la red Requerimientos, flujos y objetivos

Basado en los requisitos, flujos y objetivos de la red, un conjunto de mecanismos de candidato para cada función es evaluado, y los mecanismos deseados son seleccionados. Para facilitar la determinar donde se puede aplicar cada mecanismo, la red se divide en regiones. Funciones de la red tienen una base común en los flujos de tráfico; por lo tanto, caracterizar regiones por los flujos de tráfico permite a cada región para ser aplicado en una manera similar a todas las funciones. Las regiones comúnmente usadas incluyen acceso (edge), distribución, central (espina dorsal) y interfaces externas y DMZs. Desde una perspectiva de flujo de tráfico, acceso a regiones son donde se generan y se termina más flujos de tráfico. Regiones de distribución son donde los flujos de tráfico son agregados y terminados para servicios comunes, como los servidores de aplicación o almacenamiento. Regiones centrales preven transporte de agregados de los flujos de tráfico; flujos de tráfico individuales raramente son generados o terminados en esta región. Interfaces externas o DMZs son puntos de agregación para flujos de tráfico externos a esa red. Las características de cada región ayudan a identificar donde se aplican los mecanismos. Por ejemplo, ya que los flujos de tráfico a menudo son generados y terminados en regiones de acceso, mecanismos de funcionamiento que trabajan por flujo, tales como control de acceso y tráfico shaping, se aplicarían a estas regiones. En la región de la base, donde se agregan los flujos de tráfico, mecanismos de funcionamiento que trabajan en grupos o clases de flujos, tales como servicios diferenciados, se aplicaría. Cuando se han elegido y aplicado mecanismos de las relaciones internas entre estos mecanismos son determinadas y analizadas. En la práctica, los mecanismos, lugares y relaciones características aparecen en forma de tabla, un conjunto de tablas para cada arquitectura de componentes. Un ejemplo de las relaciones internas, en este caso el conjunto de dependencias entre los mecanismos de funcionamiento, se presenta en la figura 5.7. Debe haber un diagrama para cada característica, mostrando o no se aplicaría, y si aplica, cómo funcionaría entre cada uno de los componentes. Por ejemplo, consideremos un gráfico de dependencias. En el desarrollo de este cuadro primero empezamos por buscar mecanismos para un componente en particular — por ejemplo, rendimiento. Consideramos las dependencias entre los mecanismos dentro de cada componente. Continuar la lista, haciendo lo mismo para cada tipo de interacción. Estas relaciones se exploran con detalle en los capítulos sobre cada componente arquitectónico. Medida que avanzamos a través de las siguientes cuatro secciones (5.3.1 a 5.3.4), usted será introducido a muchos términos para los mecanismos de cada función de la red. Aunque cada

mecanismo se presenta brevemente en este capítulo, discutimos los detalladamente en los siguientes cuatro capítulos. Dependencias entre los mecanismos de funcionamiento Políticas de calidad de servicio SLAs

Dependencias de QoS en los SLAs — por ejemplo, QoS en

QoS dependencias políticas,p.

dispositivos de red puede

ej., QoS en dispositivos de red

necesitar aplicar valores de

puede necesitar hacer cumplir

SLA

las políticas

¿Dependencias de la SLA en

Por

SLAs

QoS, por ejemplo, puede ser

Dependencias políticas SLA-

exigible a través de

p. ej., SLA deba asignar a las

mecanismos de QoS

políticas de red

disponibles un SLA? Políticas de

¿Dependencias de la política de QoS, por ejemplo, una política puede ser exigible a través de mecanismos de QoS disponibles?

Dependencias de la política de SLAs

Figura 5.7 una muestra del gráfico para la lista de dependencias entre los mecanismos de

funcionamiento

En el desarrollo de la arquitectura de cada componente, tenemos que considerar el carácter dinámico de las redes. Por ejemplo, ¿cómo será la red reconfigurada para manejar un ataque de seguridad? ¿Qué sucede cuando el tráfico fluye el cambio y la congestión se produce? ¿Cuánto de cada función puede automatizarse? Cada arquitectura de componentes tendrán políticas asociadas con él. Seguridad, encaminamiento, funcionamiento y políticas de administración de red pueden tener elementos en común. Documentación de políticas en el proceso arquitectónico le ayuda a comprender las relaciones entre las arquitecturas de componente.

5.3.1 Arquitectura de componentes de direccionamiento/enrutamiento El acceso es la aplicación de identificadores (direcciones) a los dispositivos en varias capas de protocolo (por ejemplo, enlace de datos y red), mientras que el enrutamiento es aprender acerca de la conectividad dentro y entre redes y aplicar Esta información de la conectividad para reenviar los paquetes IP hacia su destino. Abordar/enrutamiento arquitectura componente describe cómo la gestión de usuarios y los flujos de tráfico se reenvían a través de la red, y cómo la jerarquía, la separación y agrupación de usuarios y dispositivos son compatibles. Esta arquitectura de componentes es importante ya que determina cómo usuario y flujos de tráfico de gestión se propagan a través de la red. Como se imaginarán, esto está muy ligado a la arquitectura de administración de red (para flujos de gestión) y la arquitectura de rendimiento (para flujos de usuario). Esta arquitectura también ayuda a determinar los grados de jerarquía y diversidad en la red, y cómo se subdividen las zonas de la red.

Hay varios direccionamiento y enrutamiento mecanismos que podrían considerarse para esta arquitectura de componentes. Desde una perspectiva de dirección, los mecanismos incluyen subredes subredes de longitud variable, supernetting, direccionamiento dinámico, privado abordar, LANs virtuales (VLANs), IPv6 y traducción de direcciones (NAT) la red. Desde la ruta (reenvío), los mecanismos incluyen la conmutación y encaminamiento, propagación de ruta por defecto, enrutamiento entre dominios sin clase (CIDR), difunde, móvil IP, filtrado de ruta, interconexión, enrutamiento políticas, confederaciones y IGP y EGP selección y ubicación. Dependiendo del tipo de red se desarrolló, el candidato direccionamiento y enrutamiento de mecanismos para una arquitectura de componentes puede ser muy diferente. Por ejemplo, una red de proveedores de servicio puede centrarse en mecanismos como el supernetting CIDR, difunde, interconexión, enrutamiento y políticas Confederaciones, mientras que una red de empresa de tamaño mediano más probablemente se centraría en classful o direccionamiento privado y NAT, VLAN, conmutación y la selección y ubicación de protocolos de enrutamiento (protocolos de gateway interior particularmente o IGP). En términos de abordar, direccionamiento classful es aplicar máscara predeterminada longitudes a direcciones para apoyar una gama de tamaños de red; las subredes utiliza parte del espacio de dirección de dispositivo (host) para crear otra capa de jerarquía; es subnetting subredes de longitud variable donde se utilizan varias máscaras de subred, crear subredes de diferentes tamaños; supernetting es agregación de direcciones de red, cambiando la máscara de dirección, para disminuir el número de bits asignados a la red; direccionamiento dinámico proporciona direcciones en la demanda; direccionamiento de IP privada está utilizando direcciones IP que no pueden ser anunciadas y transmitidas por dispositivos de red y el usuario en el dominio público (es decir, Internet); LANs virtuales son direcciones que pueden cambiar dinámicamente y reconfiguradas para acomodar cambios en la red; IPv6 es la próxima generación de direcciones IP; y traducción de direcciones de red es la asignación de direcciones IP de un reino a otro. Esto suele ser entre público y privado espacio de direcciones. En términos de transmisión, conmutación y encaminamiento son comunes expedición mecanismos; propagación de ruta por defecto es una técnica utilizada para informar a la red del defecto ruta (o ruta de último recurso); CIDR es enrutamiento basado en tamaños de máscara de dirección arbitraria (sin clases); Multicasts son paquetes dirigidos hacia varios destinos; IP móvil proporciona conectividad de red (IP) para los dispositivos que se mueven, vagan o son portátiles; filtrado de ruta es la técnica de aplicación de filtros (declaraciones) para ocultar las redes del resto de un sistema autónomo, o para añadir, eliminar o modificar las rutas en la tabla de enrutamiento; peering es un arreglo entre redes o sistemas autónomos (compañeros) mutuamente pasar tráfico y adherirse a las políticas de enrutamiento, que son declaraciones de alto nivel sobre las relaciones entre las redes o sistemas autónomos; y localización y selección de IGP y EGP implican comparación y contraste de IGPs, para seleccionar los protocolos adecuados de la red y cómo aplicarlos en la red. Dos tipos de interacciones entre mecanismos son predominantes dentro de esta arquitectura de componentes: ventajas y desventajas entre el direccionamiento y enrutamiento mecanismos y ventajas y desventajas dentro de direccionamiento o enrutamiento. Mecanismos de direccionamiento y enrutamiento influyen en la selección de protocolos de enrutamiento y donde se aplican. También forman una jerarquía de direccionamiento en el que la jerarquía de encaminamiento es overlaid.

Áreas de la red donde la dinámica direccionamiento privado abordar y red dirección mecanismos de traducción se aplican impacto cómo enrutamiento voluntad (o no) ser proporcionado a las áreas. Abordar/enrutamiento arquitectura de componentes se discute en detalle en el capítulo 6.

5.3.2 Arquitectura de componentes de gestión de red Gestión de red proporciona funciones para controlar, planificar, asignar, implementar, coordinar y controlar recursos de la red. Administración de redes es parte de la mayoría o todos los dispositivos de red. Como tal, la arquitectura de gestión de la red es importante ya que determina cómo y dónde se aplican mecanismos de gestión de la red. Es probable que los otros componentes de la arquitectura (p. ej., seguridad) requieren cierto grado de supervisión y gestión y se relacionarán con la administración de la red. La arquitectura de componentes de gestión de red describe cómo el sistema, incluyendo las funciones de red, es monitoreado y gestionado. Consiste en un modelo de información que describe los tipos de datos utilizados para supervisar y gestionar cada uno de los elementos del sistema, mecanismos para conectar a dispositivos para acceder a los datos y los flujos de datos de gestión a través de la red. Mecanismos de gestión de red incluyen monitoreo y recopilación de datos; instrumentación acceso, transferencia, actuar y modificar los datos; configuración de dispositivo y servicios; y procesamiento de datos, visualización y almacenamiento. Incluyen mecanismos de gestión de red • Monitoreo: Obtención de valores para end-to-end, por enlace y características de manejo de red

por elemento • Instrumentación: Determinar el conjunto de herramientas y utilidades necesarias para

monitorear y probe la red para la gestión de datos • Configuración: Configuración de parámetros en un dispositivo de red para la operación y control

de ese elemento • Componentes FCAPS: el conjunto de componentes de administración de fallas, configuración,

contabilidad, desempeño y seguridad • Gestión en banda y fuera-de-banda: gestión de datos fluyen por el mismo camino como tráfico

de usuarios o tener un camino por separado • Centralizado y distribuido de gestión: Si el sistema de gestión en una plataforma de hardware solo o se distribuye a través de la red entre múltiples plataformas • Escala de tráfico de red de gestión: determinar cuánta capacidad de la red debe ser reservado

para administración de redes • Controles y equilibrios: mediante múltiples mecanismos para verificar que las variables están

correctamente representadas • Gestión de datos de gestión de red: descarga de datos antiguos, hacer el seguimiento de la

disponibilidad de almacenamiento de datos, actualización de tipos de datos.

• Selección de MIB: determinar qué información de gestión de bases y cuánto de cada base,

utilizar información para la gestión • Integración en OSS: cómo el sistema de gestión se comunicará con mayor nivel de operación del

sistema de apoyo Como veremos en el capítulo 7, existen muchas interacciones dentro del componente de gestión de red. Se trata de ventajas y desventajas del enrutamiento gestión de flujos de tráfico a lo largo de las mismas rutas como flujos de tráfico de usuario (en banda), o a lo largo de caminos separados (out-banda) y centralizar todos los mecanismos de gestión por colocarlos en una plataforma de hardware solo o distribución a lo largo de la red en múltiples plataformas.

5.3.3 Arquitectura de componentes de rendimiento Funcionamiento consiste en el conjunto de mecanismos utilizados para configurar, operar, administrar, disposición y cuenta de recursos en la red que asignan el rendimiento a los usuarios, aplicaciones y dispositivos. Esto incluye la planificación de la capacidad e Ingeniería del tráfico, así como una variedad de mecanismos del servicio. Rendimiento puede aplicarse en cualquiera de las capas de protocolo y a menudo se aplica a través de múltiples capas. Por lo tanto, pueden existir mecanismos dirigidos hacia la capa de red física o capas de enlace de datos, así como de la capa de transporte y por encima. La arquitectura del componente de desempeño describe cómo recursos de la red se asignará al usuario y gestión tráfico flujos. Consiste en priorizar, programar y acondicionado los flujos de tráfico en la red, ya sea-to-end entre fuente y destino para cada flujo, o entre dispositivos de red en una base por-salto. También consiste en mecanismos para correlacionar el usuario, la aplicación y requisitos del dispositivo a los flujos de tráfico, así como tráfico ingeniería, control de acceso, calidad de servicio, políticas y acuerdos de nivel de servicio (SLAs). Calidad de servicioo QoS, es determinar, establecer y actuando en los niveles de prioridad para los flujos de tráfico. Control de recurso se refiere a mecanismos que asignar, controlar y gestionar los recursos de red para el tráfico. Sacuerdos de nivel de ervicio (SLA) son contratos formales o informales entre un proveedor y el usuario que definen los términos de la responsabilidad del proveedor al usuario y el tipo y grado de rendición de cuentas si no se cumplen estas responsabilidades . Las políticas son conjuntos (otra vez, formal o informal) de declaraciones de alto nivel sobre cómo deben asignarse entre los usuarios de recursos de la red. Este componente arquitectónico es importante que proporciona los mecanismos para controlar los recursos de red asignados a los usuarios, aplicaciones y dispositivos. Esto puede ser tan simple como determinar la cantidad de capacidad disponible en las distintas regiones de la red, o tan complejo como la determinación de la capacidad, retraso y características RMA de forma por flujo. Como discutimos en detalle en el capítulo 8, las interacciones dentro de esta arquitectura de componente incluyen las ventajas y desventajas entre end-to-end y por salto de priorización, programación y acondicionamiento de los flujos de tráfico y si los flujos son tratados individualmente, agregado en grupos, o una combinación de los dos. Como veremos, estas interacciones están estrechamente emparejadas en la capa de red (IP) para el uso de servicios diferenciados (DiffServ) y servicios (IntServ) integración dentro de la red. Servicios diferenciados e integrados son mecanismos de rendimiento estandarizados a través de la Internet Engineering Task Force (IETF) que requerimientos de desempeño individual y agregado.

Cuando se eligen las políticas, los SLAs y servicios diferenciados para la red, parte de esta arquitectura de componente describe la colocación de bases de datos para obtener información política y SLA, incluyendo puntos de decisión de políticas (PDP), puntos de aplicación de políticas (PEP), y Dispositivos de borde de DiffServ.

5.3.4 Arquitectura de componentes de seguridad La seguridad es un requisito para garantizar la confidencialidad, integridad y disponibilidad de usuario, aplicación, dispositivo e información de la red y recursos físicos. Esto es a menudo junto con privacidad, que es un requisito para proteger la santidad de usuario, aplicación, dispositivo e información de la red. La arquitectura de componentes de seguridad describe cómo son los recursos del sistema a ser protegido contra robo, daños, denegación de servicio (DOS), o acceso no autorizado. Consiste en los mecanismos utilizados para aplicar seguridad, que puede incluir tales capacidades hardware y software de redes privadas virtuales (VPN), encriptación, firewalls, filtros de enrutamiento, como traducción de direcciones de red (NAT). Cada uno de estos mecanismos puede orientarse hacia áreas específicas de la red, como en las interfaces externas o en los puntos de agregación de los flujos de tráfico. En muchos casos los mecanismos de seguridad están desplegados en las regiones, a menudo denominado zonas de seguridad o de las células, donde cada zona región o seguridad representa un determinado nivel de sensibilidad y control de acceso. Las zonas de seguridad pueden estar dentro de otra, superpuestas, o completamente separadas, dependiendo de los requisitos de seguridad y los objetivos de dicha red. Cubrimos las zonas de seguridad, como parte de la arquitectura de componentes de seguridad, en detalle en el capítulo 9. La arquitectura de seguridad y privacidad es importante ya que determina en qué medida se implementará seguridad y privacidad en la red, donde están las áreas críticas que deben fijarse, y cómo impactan e interactuar con la arquitectura componentes. Los mecanismos de seguridad que consideramos son • Análisis de amenazas de seguridad: el proceso para determinar qué componentes del sistema

necesitan ser protegidos y los tipos de riesgos para la seguridad (amenazas) deben estar protegidos contra • Las políticas de seguridad y procedimientos: declaraciones formales sobre las normas de información, red y sistema de acceso y uso, con el fin de minimizar la exposición a las amenazas de seguridad • Seguridad física y conciencia: la protección de dispositivos de acceso físico, daños y robo (incluyendo aislar todas o partes de la red de acceso exterior); y usuarios educados e involucrados con los aspectos cotidianos de la seguridad en su red y ayudarles a entender los riesgos potenciales de violación de procedimientos y políticas de seguridad • Protocolo y aplicaciones de seguridad: asegurar la gestión y red de protocolos y aplicaciones de

acceso no autorizado y uso indebido • Cifrado: Imposibilitando datos si se interceptan, mediante la aplicación cifra algoritmos junto con

una clave secreta

• Perímetro de seguridad de red: protección de las interfaces externas entre su red y redes

externas • Seguridad de acceso remoto: garantizar el acceso de red basado en tradicional dial-en las

sesiones de punto a punto y las conexiones de red privada virtual

5.3.5 Optimización de las arquitecturas de componente Determinar y entender el conjunto de las relaciones internas permiten cada arquitectura de componentes ser optimizado para una red particular. Esto se basa en la entrada de esa red particular, requerimientos, flujos de tráfico Estimado y objetivos para esa red. Haber elegido un conjunto de mecanismos para una arquitectura de componentes y determinar posibles interacciones entre estos mecanismos, requisitos, flujos y objetivos de la red se utiliza para dar prioridad a los mecanismos y las interacciones. Requisitos de usuario, aplicación y dispositivo generalmente incorporan cierto grado de rendimiento, seguridad y requisitos de gestión de red. Estos requisitos están directamente relacionados con selección y colocación de mecanismos dentro de una arquitectura de componentes y dando prioridad a las interacciones. Estima los flujos de tráfico de la red, determinado a través de la modelización y la simulación, la experiencia con el sistema existente, o a través de un conjunto de heurísticas, puede indicar agregación de puntos de tráfico o lugares donde la alta prioridad flujos (p. ej., missioncritical, en tiempo real, seguro, o OAM) es probable que ocurran. Mediante la comprensión de los tipos de flujos en la red y donde es probables que se produzca, cada arquitectura de componentes se puede desarrollar mecanismos de enfoque que óptimamente dará soporte a flujos de alta prioridad. Objetivos arquitectónicos de la red son derivadas de requisitos, determinados a partir de las discusiones con los usuarios, gerencia y personal o como una extensión del alcance y la escala de la red existente. Cuando los objetivos se desarrollan de una variedad de fuentes, proporcionan una amplia perspectiva en la que las funciones son más importantes en una red. Así, requerimientos, flujos y metas fuertemente influyen en que los mecanismos son preferidos y donde se aplican para cada arquitectura de componentes.

5.4 Arquitectura de referencia Una arquitectura de referencia es una descripción de la arquitectura de red completa y contiene todas las arquitecturas de componente (es decir, funciones) de esa red. Es una recopilación de las relaciones internas y externas desarrolladas durante el proceso de arquitectura de la red (Figura 5.8). Puede ser arquitecturas diferentes, más o menos componentes que se describen en este libro, según el enfoque de la red. Por ejemplo, la arquitectura del componente "Otros" marcada en la figura 5.8 podría ser una infraestructura de arquitectura o arquitectura de almacenamiento. Esta

flexibilidad le permite elegir las arquitecturas de componente que mejor se adapten a los requisitos de esta red. En la figura 5.8 cada arquitectura de componentes define las relaciones internas para una función determinada, mientras que la arquitectura de referencia combina estos componentes. Como veremos, arquitecturas componente pueden ponderarse para determinar sus niveles de prioridad relativa. Una vez que se desarrollan las arquitecturas de componente de una red, entonces se determinan sus relaciones uno con el otro. Estas relaciones externas son definidas por las interacciones entre pares de las arquitecturas de componente, sus ventajas y desventajas, Relaciones externas Relaciones internas (Mecanismos, ubicaciones e (Interacciones y interacciones dentro de Prioridades entre los Componentes) componentes)

Figura 5.8 modelo de proceso de enfoque de la arquitectura de componentes

dependencias y restricciones. Por lo general, todas las arquitecturas de componente de una red estrechamente están acoplados uno al otro. Esto se refleja en sus relaciones externas. Así como las relaciones internas se utilizan para optimizar cada arquitectura de componentes de la red, relaciones externas se utilizan para optimizar la suma de todas las arquitecturas de componente. Así, la arquitectura de referencia, desarrollada mediante la combinación de las arquitecturas de componente, incorpora los efectos que las funciones tienen el uno del otro. Según las exigencias, los flujos de tráfico y objetivos para una red particular, la arquitectura de referencia es equilibrada en todas las funciones o ponderada a favor de una o más funciones. En una arquitectura de red que está equilibrada en todas las funciones, se reducen al mínimo las limitaciones y las dependencias entre las funciones y compensaciones entre las funciones están en equilibrio para que ninguna función individual es prioridad sobre los demás. Cuando una o más funciones se cargan a favor sobre otros, las relaciones externas reflejan esto. Por ejemplo, en una red donde el performance es el objetivo principal de la arquitectura, se ponderarán las relaciones externas entre el funcionamiento y las demás funciones que rendimiento favor de interacciones (trade-offs en particular). Se trata de una capacidad de gran alcance que está ausente en los enfoques tradicionales. No sólo ofrece la posibilidad de decidir qué funciones se priorizan más que otros, pero esto se convierte una informada decisión, donde se entienden los efectos en otras funciones, así como en la arquitectura de referencia, y documentado como parte de la arquitectura de red. Considere una red donde el conjunto de requerimientos, flujos y objetivos indica que el bajo rendimiento de retardo y jitter son altas prioridades. Sin embargo, en esta misma red, enrutamiento, administración de redes y seguridad pueden negativamente impacto retardo y jitter rendimiento. En arquitectura de red tradicional la interacción entre el funcionamiento y las demás funciones a menudo no es bien entendida, resultando en una red de seguridad, administración de redes y mecanismos de enrutamiento aumentan el retardo y jitter, y forma la red no no cumplir con sus requisitos o metas.

Sin embargo, mediante el desarrollo de cada función como su propia arquitectura compuesto, retardo y jitter pueden optimizarse en la arquitectura de componentes de rendimiento, y luego esta arquitectura componente puede priorizarse sobre otros, para que cuando se identifican las interacciones entre el rendimiento y las otras funciones, rendimiento es elegido.

5.4.1 Relaciones externas Hasta cierto punto, cada función depende y es compatible con las otras funciones dentro de una red, así como los requisitos de los usuarios, aplicaciones y dispositivos. Esto se refleja en las relaciones externas entre sus arquitecturas de componentes. Abordar/enrutamiento arquitectura de componentes soporta flujos de tráfico de cada una de las otras funciones. Basado en los mecanismos utilizados en la gestión de redes y arquitecturas de componente de seguridad, sus flujos de tráfico pueden tomar caminos separados de flujos de tráfico de usuario, y esta capacidad debe incorporarse a abordar/enrutamiento arquitectura de componentes. Además, de enrutamiento puede configurarse para que flujos de tráfico con requisitos de rendimiento diferentes toman caminos separados a través de la red, acoplamiento abordar/enrutamiento con rendimiento. Esto es evidente en los protocolos de enrutamiento que integran mecanismos de funcionamiento, tales como multi-protocol label switching (MPLS). Cada arquitectura de componentes depende de la administración de redes para apoyar el acceso y el transporte de datos de gestión para ese componente. En la práctica, el seguimiento y gestión de abordar/routing, rendimiento y seguridad a menudo se logran mediante un enfoque integrado dentro de la arquitectura de componentes de gestión de red. En este enfoque, gestión de red es compatible con flujos de datos de gestión para cada función igualmente. En algunos casos, sin embargo, varios niveles de prioridades se asignan para el acceso y el transporte de datos de gestión para las diferentes funciones. La arquitectura de componentes de rendimiento proporciona recursos para apoyar a las otras funciones, como usuario, aplicación y flujos de tráfico de dispositivo de la red. Teniendo en cuenta requisitos de rendimiento en varios niveles de detalle (por ejemplo, toda la red, por función, por usuario/aplicación/dispositivo, o por flujo), esta arquitectura componente determina cómo mecanismos de rendimiento se utilizan para asignar recursos en el nivel adecuado de granularidad. Por ejemplo, la arquitectura de componentes de rendimiento de una red de proveedores de servicio puede enfocarse en la ingeniería del tráfico para lograr un equilibrio de todo el sistema de asignación de ancho de banda. Además, esta red puede incluir SLAs, control de acceso y priorización de tráfico, programación y acondicionado para ofrecer ancho de banda y retardo para seleccionar grupos de usuarios o aplicaciones. La arquitectura de componentes de seguridad compatible con los requisitos de seguridad y privacidad de cada una de las otras funciones. Para abordar/routing, performance y administración de redes, dispositivos de red son donde los flujos de tráfico son agregados y controlados, y a menudo requieren un alto grado de seguridad, en términos de seguridad de protocolo (por ejemplo, SNMP) y controles de acceso adicionales.

5.4.2 Optimización de la arquitectura de referencia

Requerimientos, flujos y objetivos de una red se utilizan para optimizar la arquitectura de referencia, mucho la misma manera que la arquitectura de cada componente está optimizada. Sin embargo, para la arquitectura de referencia, las interacciones se producen entre pares de las arquitecturas de componente. Hay numerosas ventajas y desventajas, dependencias y restricciones que se producen entre abordar/enrutamiento, gestión de red, rendimiento y seguridad. A continuación se presentan algunos ejemplos de las interacciones comunes entre pares de las arquitecturas de componente. Interacciones entre rendimiento y seguridad. Por su naturaleza, los mecanismos de seguridad suelen ser intrusivos, inspección y control de acceso y tráfico de red. Estas acciones requieren de recursos de la red y procesamiento, aumentando el retardo de red. Medida que se aumenta la seguridad, añadiendo más mecanismos a la red, rendimiento disminuye. Considerando que la capacidad se puede aumentar a veces para compensar una disminución del rendimiento, retraso es difícil de mitigar. Cuando el rendimiento es una alta prioridad, especialmente cuando hay que medir el rendimiento de extremo a extremo entre seleccionarlos usuarios, aplicaciones o dispositivos, mecanismos de funcionamiento pueden impedir el uso de seguridad en áreas particulares de la red. Algunos mecanismos de seguridad interrumpirán o terminan y regeneran los flujos de tráfico, afecta seriamente la capacidad para proporcionar performance end-to-end a través de una interfaz de seguridad. Como resultado, seguridad puede restringir mecanismos de funcionamiento para dentro de un perímetro de seguridad. Las interacciones entre administración de redes y seguridad. Gestión de red requiere acceso frecuente a dispositivos de red y como tal, es un problema de seguridad potencial. Gestión puede proporcionarse acceso fuera de banda a través de una red de gestión independiente, con sus propios mecanismos de seguridad. Cuando a la administración es en banda, sin embargo, cualquier mecanismo de seguridad adicional para la gestión de la red puede afectar el rendimiento para flujos de tráfico de usuario. Cuando la administración es una prioridad, una arquitectura de componentes de seguridad independiente para la gestión de la red puede estar indicada. Las interacciones entre la dirección de red y rendimiento. En la banda de la red de gestión incide directamente en el rendimiento de los flujos de tráfico de usuario, flujos de tráfico de gestión compiten con flujos de tráfico de usuario para recursos de la red. Esto es a menudo un problema en las arquitecturas de gestión de red centralizado, como todos los flujos de tráfico gestión se agregan a un dispositivo de gestión común. Como se agregan los flujos de tráfico de gestión, sus requerimientos de recursos de red pueden llegar a ser bastante grandes, especialmente durante los períodos de problemas de red. Así, un equilibrio de gestión centralizada es entre Ingeniería demasiado ancho de banda, proporcionando mecanismos de priorización para el rendimiento o reducir las expectativas de rendimiento.

Figura 5.9 componente forma arquitecturas superposiciones sobre requisitos y mapas de flujo

Interacciones entre abordar/enrutamiento y rendimiento. Rendimiento puede ser juntada de cerca con el enrutamiento a través de mecanismos tales como MPLS, distinguido e integrada de servicios y señalización mediante el protocolo de reserva de recursos (RSVP). Sin embargo, cuando ruteo simplicidad del protocolo es una prioridad alta, rendimiento puede desacoplado de enrutamiento. El resultado de este enfoque es una arquitectura de red que muestra cómo cada función se aplica perfectamente a la red, cómo las funciones interactúan entre sí y cómo pueden ser equilibrados o prioridad en la arquitectura de referencia. Una vez terminado el proceso arquitectónico tendrá un conjunto de arquitecturas componente que mienten encima de sus necesidades y mapas de flujo como se muestra en la figura 5.9. Este conjunto de superposiciones describe cómo cada función es compatible con la red, donde los mecanismos deben aplicarse y cómo interactúan uno con el otro.

5.5 Modelos arquitectónicos En el desarrollo de la arquitectura de la red hay varios modelos arquitectónicos que se pueden utilizar como punto de partida, ya sea como base de su arquitectura o construir sobre lo que ya tienes. Se presentan tres tipos de modelos: modelos topológicos, que se basan en un arreglo topológico o geográfico y a menudo se utilizan como puntos de partida en el desarrollo de la arquitectura de red; modelos basados en el flujo, que toman ventaja particular de los flujos de tráfico de la especificación de flujo; y modelos funcionales, que se centran en una o más funciones o características de la red. Es probable que tu arquitectura de referencia contendrá más de un modelo arquitectónico.

5.5.1 Modelos topológicos Hay dos modelos topológicos popular: el LAN/MAN/WAN y acceso / modelos de distribución/de la base. El modelo arquitectónico de LAN/MAN/WAN es sencillo e intuitivo y se basa en la separación geográfica o topológica de redes. Figura 5.10 muestra este modelo. Su característica importante es que, al concentrarse en los límites de LAN/MAN/WAN, se centra en las características y requisitos de esos límites y en compartimentar las funciones, servicio, rendimiento y características de la red a lo largo de los límites. El modelo de LAN/MAN/WAN y el modelo de acceso/distribución de la base (se muestra en la figura siguiente) también indican el grado de jerarquía previsto

Figura 5.10 el modelo arquitectónico de LAN/MAN/WAN

para la red. Cualquier modelo puede ser derrumbado para mostrar menos de tres niveles o ampliado para mostrar tantos niveles como sea necesario. Por ejemplo, el modelo de LAN/MAN/WAN a menudo se utiliza como un modelo de LAN/WAN, o el componente de LAN se separa en campus, edificios o incluso pisos. Descripciones de control de interfaz o ICDs, son útiles en el desarrollo de este modelo arquitectónico. ICDs definirán y describen los límites de LAN/MAN/WAN. Esto consiste en los dispositivos de red, enlaces, redes y cualquier otro elemento que se utiliza para interconectar LANs, MANs y WANs. El modelo arquitectónico de la base de distribución de acceso tiene algunas similitudes y diferencias con el modelo de LAN/MAN/WAN. Es similar al modelo de LAN/MAN/WAN que compartmentalizes algunas funciones, servicio, rendimiento y características de la red, aunque no al grado del modelo de LAN/MAN/WAN. El modelo de acceso/distribución de la base, sin embargo, se centra en la función en lugar de ubicación, como muestra la figura 5.11. Una característica de este modelo que es importante

Figura 5.11 la maqueta base de distribución de acceso

Nota es que puede ser utilizado para reflejar el comportamiento de la red en su acceso, distribución y áreas centrales. La zona de acceso más cercana a los usuarios y sus aplicaciones y es donde más los flujos de tráfico son origen y año. Así, los flujos y requisitos pueden tratarse de forma individual más fácilmente que en las áreas de distribución y núcleo. El área de distribución puede también flujos de fuentes y sumideros, pero son más probables ser a o desde dispositivos de múltiples usuarios, como servidores o dispositivos especializados. Cuantos usuarios se conectan normalmente directamente a la zona de distribución. Como tal, esta área se utiliza a menudo para consolidar flujos. Como veremos, mecanismos de funcionamiento que apoyan flujos individuales y combinados se pueden tanto utilizar aquí. El núcleo de la red se utiliza para el transporte a granel de tráfico, y los flujos no son generalmente origen o año en el centro. Así, ningún punto de vista de los flujos individuales se pierde en la base, a menos que específicamente previstas (como con los flujos que han garantizado requisitos). Los modelos de acceso/distribución/Core y LAN/MAN/WAN se utilizan como puntos de partida en la arquitectura de red, como ambos son intuitivos y fáciles de aplicar. Pueden ser restrictivas, sin embargo, en que ponen límites estrictos entre áreas. Al aplicar estos modelos, por lo tanto, tenga en cuenta que tendrá que ser creativo en cómo definir cada área, para que se ajuste a los requisitos para esa zona.

5.5.2 Modelos basados en el flujo Basada en el flujo de modelos arquitectónicos se basan en sus contrapartes, los modelos de flujo discutidos en el capítulo 4. Si usted utiliza estos modelos durante el análisis de flujo, puede ser fácil de aplicar aquí. Si bien cada modelo tiene las características de su homólogo de flujo, también tiene características arquitectónicas que no fueron discutidos en los modelos de flujo.

Los modelos de flujo que presentamos son peer-to-peer, cliente – servidor, cliente – servidor jerárquico y computación distribuida. El modelo arquitectónico de igual a igual se basa en el modelo de flujo de peer-to-peer, donde los usuarios y aplicaciones son bastante coherentes en sus comportamientos de flujo a través de la red. Las características importantes de este modelo son en las características arquitectónicas, flujos, función, características y servicios. Puesto que los usuarios y aplicaciones en este modelo son constantes a lo largo de la red, no hay obvio ubicaciones de elementos arquitectónicos. Esto empuja las funciones, características y servicios hacia el borde de la red, cerca de los usuarios y sus dispositivos y también hace flujos de extremo a extremo, entre los usuarios y sus dispositivos. Esto se asemeja a la porción de la base del modelo de acceso/distribución de la base. Figura 5.12 muestra esto

Modelo arquitectónico de la figura 5.12 el Peer-to-Peer

modelo arquitectónico. Redes ad hoc son un ejemplo de este modelo, ya que carecen de una infraestructura fija, forzando a los nodos para comunicarse de manera peer-to-peer. El modelo de arquitectura cliente – servidor también sigue su modelo de flujo, pero en este caso hay obvio ubicaciones de elementos arquitectónicos, en particular, donde se combinan flujos. Por lo tanto, funciones, prestaciones y servicios se centran en ubicaciones del servidor, las interfaces para LANs de cliente, y flujos de cliente – servidor, como se muestra en la figura 5.13. Las características del modelo cliente – servidor también se aplican al modelo de arquitectura cliente – servidor jerárquico. Además de las funciones, características y servicios están enfocados en ubicaciones de servidor y cliente – servidor de flujos, también se centran en los flujos de servidor-server (ver figura 5.14).

Figura 5.13 el modelo de arquitectura cliente – servidor

Características arquitectónicas en interfaces de servidor, interfaz de servidor LAN y en red entre los servidores

Figura 5.14 el modelo arquitectónico jerárquico cliente – servidor

Modelo arquitectónico Figura 5.15 la-computación distribuida

En el modelo de arquitectura de computación distribuida (Figura 5.15) las fuentes y sumideros son lugares obvios para elementos arquitectónicos. Modelos basados en el flujo, como los modelos topológicos, son intuitivos y pueden ser fáciles de aplicar. Puesto que son asociados con los flujos, debe asignar a cualquier mapa de flujo creado como parte del proceso de análisis de requisitos. Estos modelos son bastante generales, y quizás tenga que modificar para adaptarse a las necesidades específicas de su red.

5.5.3 Modelos funcionales Modelos arquitectónicos funcionales se centran en el apoyo a funciones particulares en la red. En esta sección presentamos a proveedor de servicios de intranet/extranet, rendimiento único / multi-con gradas y modelos de extremo a extremo. El modelo de proveedor de servicios de arquitectura se basa en las funciones de proveedor de servicios, centrándose en la privacidad y seguridad, prestación de servicios a los clientes (usuarios) y facturación. En este modelo, las interacciones entre los proveedores (las redes) y con los usuarios son compartimentadas. Si bien este modelo representa una arquitectura de proveedor de servicios, muchas redes de la empresa están evolucionando a este modelo, de aplicación en las organizaciones, departamentos y edificios. Figura 5.16 ilustra este modelo.

Intranet/extranet modelo arquitectónico se centra en la seguridad y la privacidad, incluyendo la separación de los usuarios, dispositivos y aplicaciones basadas en acceso seguro. Tenga en cuenta que en este modelo pueden existir varios niveles de jerarquía (seguridad y privacidad) (Figura 5.17).

Modelo arquitectónico Figura 5.16 el proveedor de servicios

Figura 5.17 la maqueta Intranet/Extranet

Se consideran todos los componentes en el camino de extremo a extremo del flujo de Modelo arquitectónico Figura 5.18 End-to-End

El modelo arquitectónico de funcionamiento único y multi-con gradas se centra en la identificación de redes o partes de una red como un único nivel de rendimiento, múltiples niveles de rendimiento, o componentes de ambos. Este modelo se basa en los resultados de los requerimientos y análisis de flujo, donde se determina el rendimiento single - y multi-con gradas. Hay que recordar que para el desempeño de múltiples niveles, múltiples aplicaciones, dispositivos y usuarios puede conducir a la arquitectura de red y el diseño, en términos de rendimiento, mientras que el único nivel de desempeño se centra en apoyar (generalmente la mayoría de) las aplicaciones, dispositivos, y usuarios que tienen un conjunto coherente de requisitos de desempeño. Éstos tienen dos conjuntos diferentes de requisitos arquitectónicos. Por último, el modelo de arquitectura se centra en todos los componentes en la trayectoria del extremo final de un flujo de tráfico. Este modelo se alinea más de cerca posible a la perspectiva basada en el flujo de la red (Figura 5.18). Modelos funcionales son las más difíciles de aplicar a una red, que deben entender dónde se ubicará cada función. Por ejemplo, para aplicar el modelo end-to-end primero tienes que definir donde el para cada conjunto de usuarios, aplicaciones o dispositivos que serán parte de end-toend-to-end. Una ventaja de utilizar estos modelos es que son probablemente los más estrechamente relacionados con los requisitos desarrollados durante el proceso de análisis de requisitos.

5.5.4 Utilizando los modelos arquitectónicos

Por lo general, algunos de los modelos de las tres secciones anteriores se combinan para proporcionar una visión integral de la arquitectura de la red. Esto generalmente se logra a partir de uno de los modelos topológicos y luego agregar modelos de flujo y funcionales según se requiera. Esto se muestra en la figura 5.19.

Modelos funcionales y basada en el flujo Figura 5.19 complementan los modelos topológicos

El resultado de la combinación de modelos y el desarrollo de las relaciones entre los componentes de la arquitectura es la arquitectura de referencia (Figura 5.20). En el desarrollo de la arquitectura de referencia para una red, utilizamos como entrada información de especificación de requisitos, mapa de requisitos y especificación del flujo, junto con el componente arquitecturas y modelos arquitectónicos. Ya que en este punto en el proceso no hemos desarrollado alguna de las arquitecturas de componente, nos centraremos en los modelos arquitectónicos. Como se desarrolla la arquitectura de cada componente, se integraría en la arquitectura de referencia. Como se mencionó en la sección anterior, normalmente empezamos con uno de los modelos topológicos: LAN/MAN/WAN o base de distribución de acceso y añadir a que los elementos de uno o más de los modelos funcionales o basada en el flujo. Los modelos topológicos son un buen punto de partida, ya que pueden ser utilizados para describir la

Operación, interoperabilidad, dependencias, desventajas, limitaciones Figura 5.20 la arquitectura de referencia combina los modelos y arquitecturas de componentes

toda la red de una manera general. Mientras los modelos funcionales y basada en el flujo se pueden también utilizar para describir toda una red, tienden a centrarse en un área particular de la red y así se utilizan para agregar detalles a una descripción más general. Nueve modelos han sido presentados en este capítulo (dos topológico, cuatro flowbased y tres modelos funcionales) con tantas opciones como sea posible para desarrollar su arquitectura de referencia. En la práctica, uno o dos modelos son normalmente suficientes para muchas redes. Puede aplicar un modelo para describir toda la red, con modelos adicionales para áreas específicas (por ejemplo, un modelo cliente – servidor para tener acceso a un conjunto de servidores, o un modelo de computación distribuida para centros de computación). Consideremos, por ejemplo, el modelo de acceso/distribución de la base. Las áreas de este modelo centran en diferentes funciones en la red, como fuentes de flujo de tráfico y sumideros en la red de acceso, servidor o dispositivo especializado de flujos en la red de distribución y transporte a granel de tráfico (no hay fuentes o sumideros) en la base red. Combinar este modelo con la especificación de requisitos y requisitos mapa para determinar qué áreas de la red están probables que redes de core, distribución y acceso. Determinar la red de núcleo es a menudo relativamente fácil, mientras que la determinación de las redes de distribución y el acceso puede ser más de un desafío. En algunos casos puede no haber una red de distribución, pero sólo redes de acceso y núcleo.

Desde una perspectiva de flujo, core network no fuente o fregadero de cualquier flujo, será fuente de la red de distribución serán fuente de dispositivo especializado flujos y fregadero servidores y la red de acceso y dispositivos informáticos genéricos fregadero fluye, como se muestra en la figura 5.21.

Transporte a granel de los flujos de tráfico No hay datos fuentes o sumideros

Servidores y dispositivos especializados Algunos datos fuentes y sumideros

Dispositivos informáticos genéricos Mayoría de los datos fuentes y fregaderos de aquí Figura 5.21 el modelo de base de acceso de distribución desde una perspectiva de flujo

Figura 5.22 donde modelos jerárquicos cliente – servidor y cliente – servidor pueden superponerse con el modelo de base de distribución de acceso

Dada esta perspectiva, podemos identificar redes de distribución de potencial como lugares donde se encuentran los servidores y dispositivos especializados. Entonces podemos aplicar modelos basados en el flujo de distribución y redes de acceso que tienen cliente – servidor y cliente – servidor jerárquico flujos (identificados en la especificación de flujo). Como se muestra en la figura 5.22, estos modelos se superponen con las redes de distribución y acceso. Generalmente los modelos jerárquicos de cliente – servidor y cliente – servidor se aplican a través de las áreas de distribución y acceso pero a veces también pueden solicitar a través de la base. Sin embargo, incluso cuando estos modelos se aplican a través de la base, puede no afectar la arquitectura de la red de núcleo. Como regla general, figura 5.23 muestra donde los modelos funcionales y flowbased pueden superponerse con el modelo de acceso/distribución de la base. Esta cifra no implica el uso simultáneo de estos modelos dentro de la arquitectura de una red, sino más bien donde cada modelo puede superponerse con el acceso y distribución/modelo de la base. Los resultados de los requerimientos y análisis de flujo se utilizan como entrada a la arquitectura de red, que luego conducen al desarrollo del diseño de la red. Diseño y arquitectura de red son intentos para resolver problemas no lineales, y averiguar dónde empezar puede ser difícil. No se puede iniciar en la parte superior sin cierta comprensión de las capacidades de los componentes individuales, y usted no puede escoger fácilmente componentes hasta que usted entienda los requisitos de arriba hacia abajo. Forma óptima tratamos convergen en una comprensión de todas las piezas comienzan en la parte superior y trabajar nuestro camino hacia los componentes individuales.

Figura 5.23 agregó el modelo de base de distribución de acceso con modelos funcionales y basada en el flujo

Ejemplo 5.1. La aplicación de modelos arquitectónicos. Considerar el mapa de flujo del ejemplo de almacenamiento de información en el capítulo 4, se muestra a continuación en Figura 5.24. Desde este mapa de flujo podemos determinar donde los flujos son de origen o se hunden y donde se encuentran los servidores. Esta información puede utilizarse con el modelo arquitectónico de acceso/distribución de la base, con los resultados mostrados en la figura 5.25.

Figura 5.24 el mapa de flujo del ejemplo de almacenamiento de información en el capítulo 4

Figura 5.25 acceso, distribución y áreas definidas en el ejemplo

Para este mapa de flujo, los accesos son donde los dispositivos de usuario (incluyendo la cámara de vídeo digital) se encuentran, como estos dispositivos son las principales fuentes de datos para el almacenamiento. Áreas de distribución son donde se encuentran los servidores en cada campus, ya que estos son fregaderos (como fuentes) de los datos de varios dispositivos. El área de la base se muestra entre los edificios, ya que es donde se necesita transporte de datos a granel, y no existen fuentes de datos obvios o fregaderos. Aunque como muestra que el área de la base no se encuentra en cualquier edificio en el campus, los dispositivos de red que conectarían con la zona núcleo situados en el cruce entre las zonas núcleo y las distribuciones en cada campus. En este ejemplo también podríamos aplicar un modelo arquitectónico de computación distribuida entre servidores y sus clientes. El modelo de computación distribuida es elegido aquí sobre el modelo cliente – servidor (que parece más intuitivo) como los flujos se encuentran principalmente en la dirección de los dispositivos de usuario a los servidores de almacenamiento de información. Cuando se aplica este modelo, tenemos la configuración en la figura 5.26. Hay tres áreas donde puede aplicar el modelo de computación distribuida en este ejemplo, uno en cada campus. Tenga en cuenta que en cada área los flujos dentro de la misma son de dispositivos de usuario a los servidores. En el Campus del norte también hay flujos de servidor a servidor; por lo tanto, podríamos han modificado los modelos de computación distribuida o jerárquica cliente – servidor para aplicar allí.

Figura 5.26 distribuidos computación áreas definidas para el ejemplo

5.6 Sistemas y arquitecturas de red Usted puede encontrar que, en el desarrollo de una arquitectura de red, también necesitará desarrollar una arquitectura de sistemas. Una arquitectura de sistemas (también conocido como una arquitectura de empresa) es un superconjunto de una arquitectura de red, también describe las relaciones, pero los componentes son funciones principales del sistema, tales como almacenamiento, clientes y servidores o bases de datos, así como de la red. Además, dispositivos y aplicaciones pueden ampliarse para incluir funciones concretas, tales como almacenaje. Por ejemplo, una arquitectura de sistemas puede incluir una arquitectura de almacenamiento, descripción de servidores, aplicaciones, una red de área de almacenamiento (SAN), y cómo interactúan con otros componentes del sistema. Desde esta perspectiva, la arquitectura de los sistemas considera la imagen total o integral, incluyendo la red, servidores y clientes, almacenamiento, servidores, aplicaciones y bases de datos

(Figura 5.27). Potencialmente, cada componente en el sistema podría tener su propia arquitectura. Es probable que otros componentes, dependiendo del ambiente que está apoyando a la red. En contraste, la arquitectura de red considera las relaciones dentro y entre cada uno de los elementos arquitectónicos de la red (Figura 5.28). Desde esta perspectiva, figura 5.28 es uno de los componentes de la figura 5.27. Usted puede encontrar

Conclusiones

Arquitectura de sistemas de la figura 5.27

Arquitectura de red de la figura 5.28

tienes el comienzo de una arquitectura de sistemas con su arquitectura de red. Se puede utilizar la arquitectura de red como una base desde la que construir la arquitectura de sistemas. El objetivo aquí es para que usted tenga en cuenta que el proceso de arquitectura de red puede conducir a las áreas fuera de las redes. Cuando esto sucede, usted puede ignorar esas zonas, trate de incorporar a la arquitectura de red, o ampliar la arquitectura para incluir una arquitectura de sistemas. En los capítulos 6 al 9 discutir cada uno de estos componentes de la arquitectura de red.

5.7 Conclusions El enfoque de componentes para la arquitectura de red define los bloques de la arquitectura como funciones de red en lugar de entidades físicas. De esta manera, el subyacente requisitos, flujos y objetivos de la red, en lugar de tecnologías, conducen la arquitectura de red. Este enfoque se centra en las relaciones dentro de cada componente y entre los componentes, proporciona una comprensión de cómo cada función no sólo opera dentro de una red, pero también cómo se interactúa con otras funciones. Ponderando las interacciones entre los componentes (a través de la asignación de una prioridad a cada componente), la arquitectura de red puede ser adaptada para satisfacer las necesidades específicas de una red. Arquitecturas de componentes y la arquitectura de referencia resultante pueden ser más refinados y validados a través de simulación y modelado de la red. Esto permite que las relaciones internas y externas ser estudiado largamente y apoya una progresión lógica en el proceso arquitectónico.

Aplicación del proceso revela numerosas interacciones entre las arquitecturas de componente. Las interacciones que son particularmente sutiles y complejas, como en las redes de la red, son un área en evolución de la investigación en arquitecturas de componentes. Refinación de estas interacciones es un área de trabajo en curso. Los siguientes cuatro capítulos se centran en las arquitecturas de componente. La arquitectura de direccionamiento y enrutamiento está cubierta en el capítulo 6, ya que ayuda a sentar las bases de cómo se maneja la IP en la red, que dependen todas las arquitecturas de componente. En el capítulo 7 que cubre la arquitectura de gestión de red y en el capítulo 8 la arquitectura de rendimiento. Envolvemos nuestro desarrollo de arquitecturas de componentes con el capítulo 9, la arquitectura de seguridad.

5.8 Exercises 1. Arquitectura de red define los bloques de construcción de una red como entidades físicas o funcionales. Dar ejemplos de entidades físicas y funcionales que se emplean como bloques de construcción de una red. ¿Cómo difiere cada enfoque (física y funcional)? 2. Arquitectura de una red de difiere de su diseño, en cuanto a su alcance, nivel de detalle, Descripción y ubicación de la información. Describir cómo una arquitectura y el diseño son diferentes en cada característica. 3. Arquitectura de componentes de A es una descripción de cómo y dónde se aplica cada función de la red dentro de esa red. Además de abordar/enrutamiento, gestión de red, rendimiento y seguridad, una lista de tres otras arquitecturas componente posible de una red. ¿¿Describe la arquitectura de cada componente? Mostrar cada función y capacidad y dar dos ejemplos de mecanismos (como en la figura 5.3). 4. Da ejemplos de relaciones externas entre cada una de las siguientes arquitecturas de componente: direccionamiento/enrutamiento, gestión de red, rendimiento y seguridad. Ejercicios

5. ¿Cuáles son las diferencias entre las LAN/MAN/WAN y acceso y distribución o núcleo arquitectónicos modelos? ¿Bajo qué condiciones puede cada uno aplicado a una red? 6. Considerar el desarrollo de una zona desmilitarizada (DMZ), también conocido como una LAN de aislamiento (iLAN), entre dos redes (dos diferentes sistemas autónomos [culo], administrados por diferentes organizaciones). El objetivo de una DMZ es separar y aislar las dos redes. Bosquejar brevemente lo que considera que la más importante abordar/enrutamiento requisitos de gestión, desempeño y seguridad de red y temas para una DMZ. 7. Para el ejercicio 6, ¿cuáles son algunas posibles relaciones externas entre abordar/enrutamiento, gestión de red, rendimiento y seguridad para esta DMZ? ¿Cómo tienen que trabajar juntos para alcanzar la meta de forma eficaz aislar y separar los dos sistemas autónomos las arquitecturas de componente?

CAPÍTULO CONTENIDO 6.1 Objectives 6.1.1 Preparation 6.2 Background 6.2.1 Abordar los fundamentos

6.2.2 Fundamentos de enrutamiento 6.3 Abordar los mecanismos 6.3.1 Direccionamiento Classful 6.3.2 Subredes 6.3.3 Subnetting de longitud variable 6.3.4 Supernetting 6.3.5 Direccionamiento privado y NAT 6.4 Mecanismos de enrutamiento 6.4.1 Establecer flujos de enrutamiento 6.4.2 Identificar y clasificar límites de enrutamiento 6.4.3 Manipulación de enrutamiento fluye 6.5 Abordar estrategias de 6.6 Estrategias de enrutamiento

6.6.1 Evaluación de protocolos de enrutamiento 6.6.2 Elección y aplicación de protocolos de enrutamiento 6.7 Consideraciones sobre la arquitectura 6.7.1 Relaciones internas 6.7.2 Relaciones externas 6.8 Conclusions

6.9 Exercises

248

6 Direccionamiento y enrutamiento de arquitectura Comenzamos examinando arquitecturas de componentes con la arquitectura de direccionamiento y enrutamiento. IP direccionamiento y ruteo es los pilares de una red, en la que gran parte del rendimiento, gestión de redes y arquitecturas de componente de seguridad se construyen.

6.1 Objectives En este capítulo usted aprenderá acerca de la arquitectura de direccionamiento y enrutamiento. Discutimos algunos conceptos fundamentales sobre direccionamiento y enrutamiento de redes IP y examinar varios mecanismos para proporcionar direccionamiento flexible e integral dentro de la red, así como para manipular flujos de enrutamiento a través de la red. Como con las arquitecturas de componente, se discuten posibles interacciones dentro de esta arquitectura (relaciones internas) y entre esta y otras arquitecturas de componentes (relaciones externas).

6.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con el direccionamiento y enrutamiento de conceptos para redes TCP/IP. Mientras que los mecanismos de direccionamiento discutidos en este capítulo son relativamente simples, usted debe tener algunos antecedentes de direccionamiento IP, y una buena referencia de direccionamiento se proporciona a continuación. Además, debe tener algunos antecedentes en protocolos de encaminamiento, particularmente RIP/RIPv2 OSFP y BGP4. Algunas recomendaciones de fuentes de información incluyen:

• Todo lo querías saber sobre direccionamiento IP, por Chuck Semeria, de 3Com en

www.3com.com. • Interconexiones, segunda edición, por Radia Perlman, Addison-Wesley Publishing, enero de

2000. 249 • Enrutamiento en Internet, por Christian Huitema, Prentice Hall, enero de 2000. • OSPF: Anatomía de un protocolo de enrutamiento de Internet, John T. Moy, Addison-Wesley

Publishing, enero 1998. • BGP4 Inter-Domain Routing en el Internet, por John W. Stewart, el publicar de Addison-Wesley,

enero de 1999. • Requisitos para Hosts de Internet — capas de comunicación, STD 0003, Braden r., Ed., octubre de

1989. • Requisitos para enrutadores IP versión 4, RFC 1812, F. Panadero, Ed., junio de 1995.

Los requisitos de host y router RFC y STD enumerados aquí son pesados leyendo pero describir completamente las características vitales de los hosts y routers en redes IP. Mientras que IPv6 está en el horizonte, especialmente para el gobierno y redes del prestatario de servicio, los mecanismos de direccionamiento y enrutamiento discutidos en este enfoque del capítulo sobre IPv4.

6.2 Background El componente arquitectónico final que comentaremos es una combinación de direccionamiento y encaminamiento. Direccionamiento y enrutamiento pueden considerarse arquitecturas separadas; sin embargo, de cerca se juntan en la red, por lo que se consideran aquí como partes de una arquitectura única. En este libro la arquitectura de direccionamiento y enrutamiento se centra en la capa de red (IP). Abordar, sin embargo, tiene elementos en el enlace y capas físicas (por ejemplo, direcciones de Ethernet). De enrutamiento también tiene sus contrapartes — bridging y switching, que ocurren principalmente en la física, enlace de datos y capas de red, pero (conmutación) puede ocurrir en cualquier capa de la pila de protocolos. Por lo tanto, como vas a través de este capítulo, recuerde que se pueden aplicar los conceptos discutidos en muchas capas de la red. ¿Qué son direccionamiento y enrutamiento? Direccionamiento es asignar identificadores locales o globales, privadas o públicas, temporales o persistentes, a los dispositivos. Enrutamiento consiste en aprender sobre la comunicación dentro y entre redes y aplicando esta información de accesibilidad para reenviar los paquetes IP hacia su destino. Estos dos procesos, en combinación con el elemento de direccionamiento de la arquitectura, proporcionan una imagen completa de conectividad de red. En esta sección le ofrecemos algunos conceptos fundamentales detrás de direccionamiento y enrutamiento para su revisión. Estos conceptos son necesarios para entender

el resto de este capítulo y se pasa por alto a veces en textos de protocolos de enrutamiento y enrutamiento. Este capítulo comienza con una discusión de los requisitos de direccionamiento y enrutamiento en la arquitectura de red y luego explica mecanismos de áreas funcionales y límites para establecer flujos de enrutamiento para la red. Se desarrolla una relación entre límites y flujos de enrutamiento, que conduce a las discusiones sobre las características de los flujos de distribución y cómo estas características pueden ser manipuladas. A continuación examinamos diversos mecanismos de direccionamiento y encaminamiento, incluyendo una comparación de protocolos de enrutamiento popular. Este capítulo termina entonces con el desarrollo de la arquitectura de direccionamiento y enrutamiento.

6.2.1 Abordar los fundamentos Una dirección de red es un identificador utilizado para temporal o persistente localizar un dispositivo en la red, para comunicarse con ese dispositivo. Para IP, direcciones consisten en anaddressidentifierandanassociatedmask, usuallypresentedindotted-decimalnotation (Figura 6.1). Una máscara de dirección identifica qué bits de la dirección se consideran parte de la red y (por defecto) que bits se consideran parte del dispositivo. La combinación de una dirección y la máscara permite la dirección a dividirse en una porción de red y una porción de host. Esto es importante, ya que proporciona una manera de determinar cuando una dirección es de la red local, y cuando está en una red remota. Esta decisión local y remota se discute más adelante en fundamentos de enrutamiento. En este libro las direcciones a veces aparecen en sus formatos binarios, por lo que podemos entender mejor cómo funcionan algunos de los mecanismos de direccionamiento y enrutamiento. En esta forma, cada dirección decimal se representa por su equivalente binario. Figura 6.2 muestra la dirección IP de la figura anterior, en formato binario como decimal con puntos. Máscara de identificador de dirección 129.99.30.4

255.255.240.0

Figura 6.1 IP direcciones consisten en un identificador único y una máscara

0 7 8 15 16 23 24 31

Figura 6.2 formatos de una dirección IP en binario y Decimal con puntos

Ejemplo 6.1. Dirección y cálculos de clase. Para una dirección de red de 136.178.10.1, vamos a representar esta dirección en formato binario. Los bits de cada octeto (byte) representan una potencia de 2, de 2 y0 (es decir, 1) 27 (128), como se muestra a continuación.

27 26 25 24 23 22 21 20

Potencia de 2

Valor decimal 128 64 32 16 8 4 2 1

Para representar el primer octeto de la dirección, 136, en binario, podemos sucesivamente disminuimos la mayor potencia posible de 2, hasta llegar a 0. En este caso la mayor potencia de 2 es 2 7o 128. Restando 128 de 136 nos deja con 8, que es 23. Así, 136 en binario es 10001000, como se muestra a continuación: Potencia de 2 2

7

262

5

24232

2

212

0

Valor decimal 128 64 32 16 8 4 2 1 ∗ 1 ∗ 23 = 8 128 + 8 = 136

Continuando de esta manera, obtenemos la siguiente representación binaria para 136.178.10.1: 136 = 27 + 23 178 = 27 + 25 + 24 + 21 10 = 23 + 21 1 = 20 0 0 10 10 00 1 11 0 0 11 0

0

0 0 0 0 00 0

0 1 1 0 0 0 11 0 0 00

Los números se pueden demostrar como 10001000 10110010 00001010 00000001.

Direcciones pueden ser local o global, privada o pública, temporal o persistente. Mayoría de las redes implementa las direcciones locales y globales. Direcciones locales son aquellos que son importantes en las comunicaciones locales, como las direcciones de capa de vínculo como Ethernet. Estas direcciones no se anuncian fuera de la red local. El aislamiento de las direcciones de linklayer es un ejemplo de jerarquía en la red. Sin embargo, en orden para los dispositivos fuera de esa red para comunicarse con dispositivos en la red, global direcciones son necesarias puede ser anunciado fuera de la red local. Direcciones IP se utilizan para este propósito. Direcciones IP, que han sido tradicionalmente globales en alcance, ahora pueden dividirse en espacios de direcciones públicas y privadas. Direcciones IP públicas son aquellas que pueden ser anunciados y transmitidos por los dispositivos de red en el dominio público (es decir, Internet). Direcciones IP privadas son las que no puede ser anunciada y transmitida por los dispositivos de red en el dominio público. Espacio de direcciones IP privadas se ha asignado fuera del espacio de direcciones IP previamente público. Por qué y cómo funciona esto se explica más adelante en este capítulo. Direcciones también pueden ser persistentes o temporales. Direcciones de capa de enlace (como Ethernet) pretenden ser persistente durante la vida útil del dispositivo (donde el dispositivo puede ser una tarjeta de interfaz de red [NIC]). Direcciones IP pueden ser temporales o persistentes, generalmente dependiendo de cómo se configuran dentro de la red. Direcciones temporales se asignan generalmente con un mecanismo de direccionamiento dinámico como el protocolo de configuración dinámica de host (DHCP). El grado en que las direcciones son temporales depende de cómo esté configurada la DHCP para esa red. Una dirección puede ser actualizada cada vez que un dispositivo se convierte en activo en la red, podrán ser actualizadas periódicamente mientras que un dispositivo está en la red, o puede ser asignado una vez (cuyo caso es

persistente). Direcciones persistente se asignan generalmente a los dispositivos como parte de su configuración general y no se actualizan a menos cambios en la red requieren nuevas direcciones se asignan (generalmente un proceso doloroso). Figura 6.3 muestra estos términos de dirección y sus significados.

6.2.2 Fundamentos de enrutamiento Como se mencionó anteriormente, enrutamiento implica aprender sobre accesibilidad dentro y entre redes y aplicando esta información de accesibilidad para reenviar los paquetes IP hacia su destino. En orden para los routers a los paquetes IP hacia adelantados a sus destinos, primero necesitan saber lo que están conectados a qué redes están disponibles y cómo llegar a ellos. Se trata de accesibilidad. Enrutadores aprenden accesibilidad ya sea estáticamente o dinámicamente. Para obtener accesibilidad estáticamente, routers deben tener la información configurada en ellos por personal de la red. Rutas estáticas, discutidas más adelante, son un ejemplo de cómo la accesibilidad está configurado estáticamente en un router. Por lo general, sin embargo, accesibilidad se aprende dinámicamente mediante el uso de un protocolo de enrutamiento. Protocolos de encaminamiento, como RIP/RIPv2, OSPF, BGP4, proporcionan el mecanismo para los routers aprender accesibilidad. Una vez que los routers aprenden sobre accesibilidad dentro y entre redes, esta información se utiliza para reenviar los paquetes hacia su destino. Tienda de routers Tipo de dirección

Significado

Direcciones locales

Direcciones que son reconocidas localmente, en la LAN o subred. Estas direcciones están generalmente en la capa de enlace de datos (por ejemplo, Ethernet).

Direcciones globales de

Direcciones que son reconocidas en todo el mundo. Estas direcciones están generalmente en la capa de red (IP).

Direcciones privado

Direcciones de capa de red que no se enrutan a través de la Internet pública. Direcciones privadas se utilizan en la traducción de direcciones de red (NAT).

Direcciones públicas

Direcciones de capa de red que se enrutan a través de la Internet pública.

Direcciones temporales

Direcciones de persistente

Direcciones que se asignan por un corto período de tiempo, por ejemplo, dinámicamente a través de la dinámica Host configuración de protocolo (DHCP) Direcciones que son asignadas por un período largo de tiempo o permanentemente configuradas en el dispositivo.

Figura 6.3 Dirección términos y significados

información de accesibilidad y actualizarla de vez en cuando, o a un cambio en el estado de enrutamiento en la red. Una tabla de enrutamiento, o lista de rutas, métricas, y cómo puede ser alcanzados, es un mecanismo común utilizan routers para mantener dicha información.

Routers de reenvían paquetes basados en la accesibilidad. Tradicionalmente, un router examina la porción de red de la dirección de destino de un paquete para determinar donde debe ser enviado. El router compara este destino para el contenido de su tabla de enrutamiento y elige la mejor ruta para ese destino. Si hay varias rutas posibles, el mejor camino es el que está con el partido más largo (o más explícito). Figura 6.4 muestra un ejemplo de esto. En este ejemplo la empresa A tiene la Dirección 129.29.0.0 con una máscara de red de 255.255.0.0, que es de 16 bits de longitud. Empresa B tiene la Dirección 129.99.10.0 con una máscara de red de 255.255.255.0, que es de 24 bits de longitud. Se examinarán los paquetes IP desde Internet en el router ISP Z, donde se comparan las direcciones de destino de estos paquetes con entradas en la tabla de enrutamiento. Al comparar la dirección de destino de un paquete con entradas de una tabla de enrutamiento, es elegido el partido más largo en la dirección de destino. Por ejemplo, un paquete IP al llegar a Z ISP con una dirección de destino de 129.99.10.1 con dos entradas en la tabla de enrutamiento que se muestra en la figura 6.4. Cuando se aplica la máscara de red de la primera entrada en la tabla de enrutamiento, 255.255.0.0, al 129.99.0.0, obtenemos 129,99 como el

Figura 6.4 tráfico se reenvía basado en el partido más largo de dirección (más explícito)

red. Esto coincide con los dos primeros octetos del paquete IP con 129.99.10.1 como su dirección. Asimismo, cuando se aplica la máscara de red de la segunda entrada en la tabla de enrutamiento, 255.255.255.0, a 129.99.10.0, tenemos 129.99.10 como la red. Esto también coincide con nuestro paquete IP, con 129.99.10.1 como su dirección, pero coincide con los tres primeros octetos, un partido más (más explícito). Como resultado, los paquetes con una dirección de destino de 129.99.10.1 se reenvían al ISP Y. Generalmente es una ruta por defecto, que es la ruta usada cuando no hay ninguna otra ruta para ese destino. Es la ruta de último recurso y es útil cuando un montón de flujos de tráfico a un enrutador de nivel superior o red (por ejemplo, una hogar o negocio conexión a un ISP). Enrutadores también pueden mirar las etiquetas en un paquete y utilizar la información de enrutamiento. Conmutación por etiquetas multiprotocolo (MPLS), discutido más adelante en este libro, utiliza este mecanismo. Enrutamiento es convergente con el cambio, y a veces es difícil entender las diferencias entre los dos. Una comparación de enrutamiento y conmutación se presenta en el capítulo 11. Direccionamiento y enrutamiento se utilizan juntos para formar una imagen global de la conectividad de la red. Un ejemplo de ello es la decisión local o remota para determinar dónde inicialmente enviar paquetes. En la decisión local o remoto, un dispositivo (como equipo de un usuario) tiene que decidir si el destino de un paquete es local (en la misma red) o remoto. La dirección IP de destino y la máscara (discutido anteriormente) se utilizan para determinar la porción de red de la dirección de destino. Esto se compara con la porción de red de la dirección IP del dispositivo. Si son lo mismo, el destino está en la misma red (es decir, es local). Si las porciones de la red de las direcciones IP son diferentes, están en redes diferentes (remotas). ¿Por qué es importante? Parte fundamental del comportamiento de la propiedad intelectual es en la presente decisión local y remota (Figura 6.5). IP exige que, si la dirección de destino es local,

entonces hay un mecanismo de nivel inferior para el transporte directamente de ese paquete. Como parte de este requisito, cada dispositivo en una IP red (o subred, como se ver más adelante) deben ser capaces de comunicarse directamente con todos los dispositivos en esa red. Esto significa que la red subyacente debe tener un mecanismo para permitir que todos los dispositivos para comunicarse con cada otro dispositivo. Esto tiene implicaciones para cómo se hace la resolución de la dirección en las capas inferiores, como vemos más adelante en este libro. IP exige también que, si la dirección de destino es remota, entonces hay un router que puede reenviar ese paquete hacia su destino. Así, un dispositivo en la red necesita saber sobre que router o routers pueden reenviar paquetes. Esto puede ser aprendido por el dispositivo, a través de escuchar a actualizaciones de enrutamiento protocolo, o se puede configurar en el dispositivo. Este router se denomina el router del siguiente salto para esa red. En la figura 6.5 dispositivos en la misma subred, 129.99.0.0, deben conectarse directamente en las capas MAC/PHY. Dispositivos están en la misma subred cuando tienen la misma dirección de red, determinados aplicando la máscara de red en sus direcciones. En el ejemplo de la figura 6.5 dispositivos 129.99.0.1 y 129.99.0.2 están en el mismo

Principios básicos de la figura 6.5 de reenvío de IP

red, como la máscara de red (/ 16 o 255.255.0.0) aplicada a cada dirección tiene una red de 129.99.0.0. IP asume esta conectividad y pasa datagramas IP hasta las capas MAC y PHY para transporte. Cuando los dispositivos están en redes diferentes, debe haber un router que puede reenviar tráfico entre dichas redes. En el ejemplo, el tráfico entre 129.99.0.0 y 136.178.0.0 pasa a través del router adyacente, que tiene interfaces en ambas redes.

6.3 Abordar los mecanismos En esta sección se discuten algunos de los mecanismos populares para hacer frente a las redes: direccionamiento clase, subredes, subnetting de longitud variable, superredes y enrutamiento entre dominios sin clase (CIDR), direccionamiento privado y red dirección traducción (NAT) y direccionamiento dinámico. Aunque estos mecanismos todos comparten básicamente el mismo tema (manipulación de espacio de direcciones), les tratamos como independiente con el fin de resaltar sus diferencias.

Cabe señalar que el concepto de atender en clase es un poco anticuado. Discutimos aquí dar algunos antecedentes sobre los nuevos mecanismos y para proporcionar la penetración en el proceso de direccionamiento.

6.3.1 Direccionamiento clase Direccionamiento Classful es aplicar máscara predeterminada longitudes a direcciones para apoyar una gama de tamaños de red. El resultado es un conjunto de clases de direcciones (A, B, C, D y E), cada uno de ellos soporta un tamaño de red máxima diferente. Un identificador de clase al principio (primer octeto) de la dirección determina su clase. Una dirección clase A se indica cuando el primer bit del primer octeto es 0 (direcciones de red 1 a 127), una dirección de clase B es cuando el primer bit es 1 y el segundo bit es 0 (direcciones de red 128 a 191), y una dirección de clase C cuando el primer bit es 1 , el segundo bit es 1, y el tercer bit es 0 (direcciones de red 192 a 223). Las estructuras de las clases A, B y C se muestran en la figura 6.6. Las clases D y E no se muestra aquí, como se utilizan para propósitos especiales (clase D se utiliza para multicast) o reservadas. Classful direcciones de forma predeterminada, una mascarilla natural que coincide con el límite de clase y refleja asignaciones de espacio de red y host de la clase. La máscara natural es diferente para cada clase. Para direcciones de clase A la máscara natural es 255.0.0.0, indicando que los bits del primer octeto representan la red para esa clase. Puesto que el primer bit del primer octeto se utiliza para indicar una dirección de clase A y ni todos 0s Clase a (1 – 127) (127 redes, sobre M 16 direcciones de red) 0 7 8 31

Clase C (192 – 223) (2M de redes, 254 direcciones de red) 0 1 2 3 23 24 31 0

11

Host de la red Direccionamiento clase Figura 6.6 utiliza límites de clase tradicional forma clase A, B o C direcciones

ni todos 1s puede usarse como direcciones de red (que representan las emisiones), puede haber 27−2 o 126 redes posibles. La porción del dispositivo (host) de la máscara es los restantes tres octetos, por lo que puede haber hasta 224−2 o dispositivos más 16 millones de posibles direcciones por la red para redes de clase A. Así, clase A proporciona para algunas redes muy grandes. La máscara natural para direcciones de clase B es 255.255.0.0, los dos primeros octetos representan la red de esa clase. Puesto que los primeros dos bits se utilizan para identificar la clase, pueden ser 2 −214o 16.382 redes posibles. La porción del dispositivo de la mascarilla es los dos octetos restantes, por lo que puede haber hasta 216−2 o 65.534 direcciones de dispositivos posibles por red. Así, clase B proporciona para decenas de miles de redes (aún bastante grandes). Al mismo tiempo esto parecía como un montón de redes, pero ya no. La máscara natural para direcciones de clase C es 255.255.255.0, por lo que los tres primeros octetos representan la red de esa clase. Puesto que los primeros tres bits se utilizan para identificar la clase, puede ser 221−2 o levemente sobre 2 millones de redes posibles. La porción del

dispositivo de la mascarilla es el octeto restantes, por lo que puede haber hasta 28−2 254 direcciones de dispositivos posibles por red. Así, clase C ofrece para millones de pequeñas redes. Hay dos clases adicionales de espacio de dirección (clases D y E) que son utilizados o reservados para propósitos especiales. Clase D se utiliza para direcciones de multicast y clase E está reservado. Espacios de direcciones de clase D se calculan de la misma manera como las otras clases, así que clase D está indicado cuando el primer, segundo y tercer bits del primer octeto son 1, y el cuarto bit es 0 (direcciones de red 224 a 239). Direccionamiento clase fue el primer paso para añadir jerarquía a abordar. Aunque las tres clases pueden abordar desde muy pequeño para redes muy grandes, hay algunos problemas fundamentales con este esquema. En primer lugar, redes de clase A y B pueden tratar gran número de dispositivos. Resulta que, redes no escala bien para el tamaño de un clase A o B, y es necesario más jerarquía. Y, como dirección de clase A y B espacio funcionó hacia fuera, el uso de la clase C dirección espacio impactado encaminamiento en Internet. Claramente, algo más de lo que era necesario abordar clases.

Ejemplo 6.2. Determinar la clase y mascarilla Natural. Para la dirección de red del ejemplo 6.1, 136.178.10.1, vamos a determinar su clase y la mascarilla natural. Recuerde del ejemplo 6.1 la representación binaria de 136.178.10.1: 136 = 27 + 23 178 = 27 + 25 + 24 + 21 10 = 23 + 21 1 = 20 10 00 10 10 01 00 11

1 0 0 0 1 0 0 000 0 0 0 0 0 0 0 1

Mirando los primeros tres bits (de izquierda a derecha) del primer octeto, vemos que son 100. Puesto que el primer bit debe ser 0 para una dirección de clase A, 136.178.10.1 no es clase A. Los dos primeros bits son 10, que son consistentes con la clase B; por lo tanto 136.178.10.1 es una dirección clase B. La máscara natural para esta dirección es la máscara natural de clase B, 255.255.0.0.

Existen limitaciones en la asignación de direcciones basadas en los límites de clase A, B y C. En primer lugar, dado que hay relativamente pocas direcciones de clase A y B, ellos ya se han asignado. Esto deja nuevas redes con sólo espacio de direcciones de clase C. Así, una red puede requerir muchas direcciones de clase C. En segundo lugar, estos límites de clase no son un uso eficiente de direcciones de red. Muchas redes requieren direcciones más que una sola clase C pueden proporcionar, pero no son lo suficientemente grandes como para justificar una clase A o B, incluso si tales direcciones de red disponibles. Hay redes que tienen direcciones de clase A o B, pero pueden utilizar sólo una pequeña fracción del espacio de dirección total. Se necesita para ser un método más flexible para que coincida con el espacio de dirección a las necesidades de cada red. Esto se logró mediante la expansión de la máscara de red para crear subredes y subredes de longitud variable, como se describe a continuación.

6.3.2 Subnetting El siguiente paso en la adición de jerarquía para resolver es permitir una dirección de red clase a ser segmentados en secciones más pequeñas. Subnetting (RFC 950) logra esto. Las subredes utiliza

parte del espacio de dirección de dispositivo (host) para crear otro nivel de jerarquía. Cambiar la máscara de dirección aumenta el número de bits asignados a la red, crear la subred. La máscara resultante ahora incluye una máscara de subred, y los segmentos de red que se crean se llaman subredes . Esencialmente lo que está sucediendo en las subredes es que, al cambiar la máscara de dirección para aumentar el número de bits asignados a la red y disminuyendo el número de bits asignados a los dispositivos, las subredes toma espacio de direcciones de dispositivos y le da a la red. Las subredes se pueden hacer en redes clase A, B o C, aunque es raro a la subred de una red de clase C (ya que sólo hay 254 direcciones para dispositivos de todos modos). El resultado de las subredes es un conjunto de subredes de igual tamaño, donde la longitud de la máscara de subred determina el número de subredes y el tamaño de cada subred. Un ejemplo de esto para redes de clase B se muestra en la figura 6.7. Las subredes agrega jerarquía a una red. Una red en la que todos los dispositivos se tratan con la misma dirección de red puede tener problemas a un gran número de dispositivos. El término "grande" es relativo: algunas redes tienen problemas

Figura 6.7 máscaras y tamaños para las subredes de una red de clase B

con algunos docena dispositivos, mientras que otros pueden escalar a cientos de dispositivos sin problemas. Los problemas están generalmente relacionados con cargas de tráfico y comportamiento en las capas físicas y enlace. Los comportamientos de los usuarios, aplicaciones y dispositivos se reflejan en los flujos de tráfico en la red y la escalabilidad de la red de impacto de las características de estos flujos (incluyendo sus fuentes y sumideros). Cómo se configuran los dispositivos de red en la capa de enlace afecta a cómo se comunican en esa capa. Problemas en la capa de enlace, tales como Farfullar dispositivos o las tormentas de broadcast/multicast, impactan de escalabilidad de la red. Las subredes ayuda a reducir el problema al segmentar la red en subredes conectadas por routers. Routers de terminan el enlace y capas físicas, parando así problemas en una subred de afectar a otras subredes. Máscaras de subred (y por lo tanto las subredes) son reconocidas solamente dentro de esa red. Cuando se anuncian las rutas a esa red, se utiliza la mascarilla natural. Esto es deseable; desde las subredes se utilizan para proporcionar la jerarquía dentro de esa red, no hay necesidad para revelar esa jerarquía fuera de la red. Ejemplo 6.3. Creación de subredes. Vamos a 129.99.0.0 de subred en siete subredes. 129.99.0.0 es una clase B (¿cómo sabemos esto?) dirección con una mascarilla natural de 255.255.0.0. Para crear subredes, aumentamos la máscara en el tercer octeto por suficientes bits para siete subredes. De la figura 6.7, vemos que tres bits nos dará siete subredes usando una máscara extendida (máscara de subred) de 255.255.224.0, como se muestra a continuación. 255 255 224 0 11 1 1 11

1

1110

0 0 0 0

1 1 1 1 1 1 1 1 10 0 0 0 0 0 0 0 Tres bits a la máscara para crear subredes

A continuación se muestra cada subred en binario y decimal con puntos. Subred 1:10000001 01100011 00100000 00000000129.99.32.0 255.255.224.0

Subred 2:10000001 01100011 01000000 00000000129.99.64.0 255.255.224.0 Subred 3:10000001 01100011 01100000 00000000129.99.96.0 255.255.224.0 Subred 4:10000001 01100011 10000000 00000000129.99.128.0 255.255.224.0 Subred 5:10000001 01100011 10100000 00000000129.99.160.0 255.255.224.0 Subred 6:10000001 01100011 11000000 00000000129.99.192.0 255.255.224.0 Subred 7:10000001 01100011 11100000 00000000129.99.224.0 255.255.224.0

6.3.3 Subnetting de longitud variable Subredes de segmentos de una red en varias subredes de igual tamaño a menudo es ineficiente. Si una meta de las subredes es crear subredes que se escalan a los tamaños de los grupos (grupos de trabajo) en la organización, para que una subred puede ser asignada a cada grupo, es conveniente tener subredes de diferentes tamaños. Es subnetting subredes de longitud variable donde se utilizan varias máscaras de subred de longitud variable (VLSM), creación de subredes de diferentes tamaños. Esta práctica permite una mejor asignación de subredes para grupos de trabajo. Por ejemplo, la siguiente organización tiene un número de grupos de trabajo de diferentes tamaños. Grupo de Grupos Tamaño grupo trabajo (dispositivos) De la 3 400 (1200 en total) ingeniería De marketing 1 1950 Administración 1 200 Ventas 15 35 – 90 (1350 total) R&D 1 150 Apoyo 22 10 – 40 (880 total) Total: 43 Total: 5730 Esta organización tiene una dirección de clase B (136.178.0.0, máscara 255.255.0.0) y quisiera darle una subred a cada grupo. Si tuviéramos que utilizar sólo la mascarilla natural, esta red apoyará 65.534 dispositivos, que es mucho más que necesario. Sin embargo, es probable que la red tendría problemas a ese tamaño. No podemos implementar subredes de igual tamaño, dado el requisito de una subred por grupo. Para apoyar el grupo más grande (Marketing, con dispositivos de 1950), sería necesario una máscara de subred de 5 bits o menor. Pero esto daría un máximo de 31 subredes posibles (con una máscara de 5 bits). Con el fin de tener suficiente subredes, necesitaríamos una máscara de subred de 6 bits o más, pero entonces el tamaño de la subred no sería lo suficientemente grande como para comercialización. Mediante el uso de subredes de longitud variable, podemos adaptar las subredes para los tamaños de los grupos y la cantidad de subredes que necesitamos. Para este ejemplo elegimos usar una combinación de máscaras de subred de 4 bits y 8 bits. Con una máscara de 4 bits (255.255.240.0), tendríamos 15 subredes, cada una con un máximo de 4096 dispositivos. Esto sería suficiente para la ingeniería y Marketing. La máscara de subred de 8 bits (255.255.255.0) proporciona subredes que pueden tener un máximo de 254 dispositivos cada uno, suficiente para cada uno de los grupos de ventas, I+d y apoyo.

Las asignaciones de subred son los siguientes: los 4 bits de la máscara (255.255.240.0) se utiliza para asignar las siguientes 15 subredes: 136.178.16.0 136.178.96.0 136.178.176.0 136.178.32.0 136.178.112.0 136.178.192.0 136.178.48.0 136.178.128.0 136.178.208.0 136.178.64.0 136.178.144.0 136.178.224.0 136.178.80.0 136.178.160.0 136.178.240.0 No todas estas subredes se utilizaría en este momento. Asignamos tres subredes para ingeniería (136.178.16.0, 136.178.32.0 y 136.178.48.0), una subred para Marketing (136.178.64.0) y probablemente debería asignar uno a la administración (136.178.80.0), ya que sería cerca del número máximo de dispositivos para una subred de 8 bits. Para la máscara de 8 bits, tomar una de las subredes de 4 bits y aplicar la máscara de 8 bits a él. Podríamos tomar la siguiente subred de 4 bits disponibles (136.178.96.0) y aplicar una máscara de 8 bits (255.255.255.0), produciendo las siguientes subredes de 8 bits: 136.178.97.0 136.178.102.0 136.178.107.0 136.178.98.0 136.178.103.0 136.178.108.0 136.178.99.0 136.178.104.0 136.178.109.0 136.178.100.0 136.178.105.0 136.178.110.0 136.178.101.0 136.178.106.0 136.178.111.0 Estas son todas las subredes de 8-bit entre 136.178.96.0 y 136.178.112.0. Cada uno puede apoyar hasta 254 dispositivos. Asignar 15 de estas subredes (136.178.97.0 a través de 136.178.110.0) a las ventas y el último uno (136.178.111.0) a i+d. En este punto que tenemos que crear más subredes de 8 bits (22 subredes por apoyo), así que se repita este procedimiento para las dos subredes de 4 bits disponibles (136.178.112.0 y 136.178.128.0). Para 136.178.112.0: 136.178.113.0 136.178.118.0 136.178.123.0 136.178.114.0 136.178.119.0 136.178.124.0 136.178.115.0 136.178.120.0 136.178.125.0 136.178.116.0 136.178.121.0 136.178.126.0 136.178.117.0 136.178.122.0 136.178.127.0 y para 136.178.128.0: 136.178.129.0 136.178.134.0 136.178.139.0 136.178.130.0 136.178.129.0 136.178.140.0 136.178.131.0 136.178.136.0 136.178.141.0 136.178.132.0 136.178.137.0 136.178.142.0 136.178.133.0 136.178.138.0 136.178.143.0 Las 22 subredes apoyo sería 136.178.113.0 a través de 136.178.127.0 y 136.178.129.0 a través de 136.178.129.0. Las subredes restantes de 4 y 8 bits estaría disponibles para el crecimiento futuro.

6.3.4 Supernetting Como se mencionó anteriormente, no hay muchas redes de clase A y B (del orden de decenas de miles). Como estas redes fueron asignados, se hizo necesario asignar varias direcciones de red clase C en lugar de una sola clase A o B. recordemos que hay millones de redes clase C que pueden distribuirse. ¿Qué sucede cuando se utilizan direcciones de clase C en lugar de direcciones de clase A o B? Consideremos, por ejemplo, la estrategia de dirección para una empresa con 10.000

dispositivos. Una sola clase B podría apoyar hasta 65.534 dispositivos, que serían suficiente para esta empresa, pero un clase B no está disponible, para que direcciones de clase C se utilizan en su lugar. Una sola clase C puede soportar hasta 254 dispositivos, por lo que se necesitan 40 redes de clase C (40 × 254 direcciones de red de redes = 10, 160 direcciones total). Cuando 40 redes de clase C se asignan a esta empresa (por ejemplo, 192.92.240.0 a través de 192.92.279.0), las rutas a cada red tienen que anunciarse en Internet. Así, en vez de un anuncio de una sola red de clase B para esta empresa, tenemos anuncios para redes de clase C 40. Cada anuncio de ruta se sumarían a los enrutadores de Internet, usando memoria y recursos de procesamiento. Como se puede imaginar, el número de rutas crecería exponencialmente, como la memoria y procesamiento de requerimientos en los routers. De hecho, esto era un problema en el Internet en la década de 1990. Hubo predicciones que Internet se colapsaría en 1995, sin embargo, esto no sucedió. Mediante el ingenio de los ingenieros de Internet en ese momento, se encontró un mecanismo para aliviar este problema. La solución fue supernetting. Supernetting es agregación de direcciones de red, cambiando la máscara de dirección para disminuir el número de bits, reconocida como la red. Al disminuir el número de bits, reconocida como la red, estamos en efecto ignorando parte de la dirección de red, que resulta en la agregación de direcciones de red. Vamos a ver cómo funciona. Consideremos un bloque de 16 direcciones de clase C contiguas (pronto verá por qué fue elegido el 16, y por qué es contiguo), 192.92.240.0 mediante 192.92.255.0, con su natural máscara 255.255.255.0: 192.92.240.0 192.92.248.0 192.92.241.0 192.92.249.0 192.92.242.0 192.92.250.0 192.92.243.0 192.92.251.0 192.92.244.0 192.92.252.0 192.92.245.0 192.92.253.0 192.92.246.0 192.92.254.0 192.92.247.0 192.92.255.0 Aviso que la primera, segunda y última octetos de este grupo de direcciones no cambian. Son 192, 92 y 0, respectivamente. El tercer octeto cambia para cada dirección. Si nos fijamos en la representación binaria de este octeto para las direcciones, obtenemos la figura 6.8. Observe que los primeros cuatro bits de este octeto no cambian, pero los últimos cuatro bits. Observe también que los últimos cuatro bits se representan en su amplia gama de Original dirección máscara 255.255.255.0

192.92.240.0 192.92.241.0 192.92.242.0 ... 192.92.254.0 192.92.255.0

Nueva máscara, 255.255.240.0 o 20 bits de largo (puede ser máscara de dirección Representado como 20) reducido por 4 Bits Figura 6.8 modificar la máscara de dirección de Supernetting

valores, desde 0000 (binario) a 1111. Por lo tanto, si decidimos ignorar los últimos cuatro bits de este octeto, obtenemos una única dirección que representa el rango completo de direcciones de 16. Esa dirección es 192.92.240.0 (la primera dirección del grupo), y su máscara es 255.255.240.0 (la mascarilla natural menos los últimos cuatro bits). Esta máscara se denomina la máscara supernet . ¿Cómo funciona eso? Primero veamos 192.92.240.0 con su mascarilla natural, 255.255.255.0. Estas direcciones se muestran en la figura 6.9 como representaciones decimales y binario. Cuando se aplica la mascarilla natural para la dirección, obtenemos una sola red clase C con 254 direcciones de dispositivo. Si nos fijamos en esta red con la nueva máscara de supernet, obtenemos la figura 6.10. La diferencia aquí es que, con la nueva máscara de supernet, los últimos cuatro bits del tercer octeto no son reconocidos como parte de la red; por lo tanto pueden ser

Máscara natural (Decimal) 255 255 255 0 1111111 1

11111111

1111111 1

0000000 0

1111000 0

0000000 0

Máscara natural (binario)

Dirección 192 de red 92 240 0 1100000 0

01011100

(Decimal) Dirección de red (binario)

Resultado: Una red de clase "Normal", solo C Figura 6.9 una dirección IP con su máscara Natural

Supernet máscara 255 (Decimal) 255 240 0 1111111 1

11111111

1111000 0

0000000 0

Máscara de Supernet (binario)

Reconocido Dirección 192 de red 92 240 0 1100000 0

01011100

1111000 0

0000000 0

(Decimal) Dirección de red (binario)

Estos bits pueden ser cualquier cosa Figura 6.10 una dirección IP con una máscara de Supernet

cualquier cosa (0000 a 1111). Como resultado, obtenemos un conjunto de 16 direcciones, desde 192.92.240.0 (donde los últimos cuatro bits del tercer octeto son 0000) a 192.92.255.0 (donde los últimos cuatro bits del tercer octeto son 1111). Así, el solo anuncio de 192.92.240.0 con supernet máscara 255.255.240.0 es el equivalente de 16 anuncios de direcciones de 192.92.240.0 a través de 192.92.255.0. Supernetting redujo el número de anuncios en Internet y había cambiado la forma en que la mayoría de la gente ve abordar. Si podemos cambiar la longitud de la máscara a las redes globales, ¿por qué necesita clase límites en todo? La respuesta es que no lo hacemos. El término de encaminamiento entre dominios sin clase (CIDR) se utiliza para denotar la ausencia de límites de clase en enrutamiento de red. La notación decimal con puntos para las máscaras puede sustituirse por observando la longitud de la máscara en pedacitos. Por ejemplo, la Revita máscara 255.255.240.0 demostrado descrita previamente como una máscara de 20 bits, y la combinación de dirección y la máscara sería 192.92.240.0/20. El bloque de redes que tratan de esta manera se denomina un bloque CIDR. Mediante este Convenio, una sola red de clase C tendría una longitud de la máscara de 24 bits (/ 24), y una única red de clase B tendría una longitud de la máscara de 16 bits (/ 16). Cuando una máscara se muestra como una longitud en bits se denomina un Prefijo de dirección . Describiendo las redes de esta manera estamos realmente creando jerarquías arbitrarias en la red. Cambiando la longitud de la máscara podemos cambiar el grado de agregación de redes. Esto es práctica común en la comunidad de Internet. Hay algunas convenciones que se siguen en superredes: el número de direcciones en un bloque CIDR es una potencia de 2, y el bloque de direcciones contiguo, lo que significa que hay no hay agujeros en dicho espacio de direcciones. El número de direcciones en un bloque CIDR es una potencia de 2, basado en el número de bits que no es reconocido por la máscara. Si nos fijamos en 192.92.240.0 con una/24 (la mascarilla natural), obtenemos una red: 192.92.240.0. Con la máscara de un/23, ignoramos la última parte del tercer octeto, y obtenemos dos redes: 192.92.240.0 y 192.92.240.1. Como se puede ver en la figura 6.11, esto puede continuar durante 22, 21 y así sucesivamente. Cada vez que aumentamos el número de redes posibles por un factor de 2. Cuando el espacio de direcciones no es contiguo (es decir, hay una o varias direcciones de red que falta del bloque CIDR), existe la posibilidad de problemas. En nuestra discusión sobre superredes debe quedar claro que, en el proceso de cambio de la longitud de la máscara, ignorar algunos de los bits de la dirección. Los bits que se omiten pueden tomar cualquier valor, y el resultado es que se asume una gama de redes. Si uno o más de las redes en ese rango no son parte del bloque CIDR (por ejemplo, que la dirección de red se está utilizando por otra persona), todavía se anuncia como parte de la gama de direcciones en ese bloque. Dirección (Decimal) 192 de red 92 240 0

Figura 6.11 el tamaño del prefijo de direcciones determina el tamaño del bloque CIDR

Por ejemplo, el anuncio 200.1.128.0/17 es equivalente a un rango de 27 o 128 redes, desde 200.1.128.0 a 200.1.255.0. Si una de estas direcciones, decir 200.1.200.0/24, ya se asigna a otro cliente, todavía se incluye en el anuncio 200.1.128.0/17. ¿Esto significa que los anuncios no pueden tener cualquier estos "agujeros" en ellos? No. Afortunadamente, este método todavía

funciona. Como comentamos al principio de este capítulo, routers de elegir a la mejor combinación para un destino. Dado un número de rutas (en la tabla de reenvío del router) que funcione, el router elige es el partido más largo en la dirección de destino del paquete. Si la red 200.1.200.0/24, que está en el bloque CIDR anuncio 200.1.128.0/17, es propiedad de alguien, se reenvían paquetes con una dirección de destino de 200.1.200.0/24 a la 200.1.200.0 de la red, ya que es un mejor partido (más) que 200.1.128.0/17.

6.3.5 Direccionamiento privado y NAT Direcciones IP privadas son las que no puede ser anunciada y transmitida por los dispositivos de red en el dominio público. Esto originalmente fue establecida para ayudar con el agotamiento del espacio de dirección en el Internet, para si redes que normalmente serían asignar espacio de direcciones públicas en lugar de otro utilizan el espacio de direcciones privado, las direcciones públicas quedarían disponibles. El IETF ha definido (en el RFC 1918) tres bloques de espacio de direcciones privado: 10.0.0.0 a 10.255.255.255 (Prefijo de 10/8) 172.16.0.0 a 172.31.255.255 (prefijo 172.16/12) 192.168.0.0 a 192.168.255.255 (prefijo 192.168/16)

Hay un beneficio lateral del uso de direcciones privadas. Resulta que ya que estas direcciones no anunciadas y transmitidas en Internet, tienen un grado adicional de seguridad. Lo que se necesita para abordar privado para trabajar, sin embargo, es un mecanismo para traducir las direcciones del espacio de dirección privado al espacio público. Traducción de direcciones de red (NAT) es un mecanismo de este tipo. NAT asigna direcciones IP entre espacios públicos y privados. En la traducción entre espacios de direcciones públicas y privadas, NAT crea enlaces entre direcciones. Éstos pueden ser enlaces de dirección uno a uno (conocidos como NAT estática), enlaces de dirección de uno a muchos (conocida como NAT dinámico) y los enlaces dirección y el puerto (conocidas como traducción de puerto de direcciones de red o NAPT). Se utilizan a menudo combinaciones de estática, dinámica y los enlaces de NAPT en una red. Por ejemplo, NAT dinámico a menudo se utiliza para dispositivos de usuario y NAT estático para servidores.

6.4 Mecanismos de enrutamiento Los mecanismos de encaminamiento que consideramos aquí están estableciendo flujos de distribución, identificación y clasificación de límites enrutamiento y manipular flujos de enrutamiento.

6.4.1 Establecer flujos de enrutamiento En la preparación para discutir límites y manipulación de la ruta, queremos entender cómo los flujos probablemente se enrutarán a través de la red. Como vemos más adelante en este capítulo, direccionamiento y enrutamiento son ambos estrechamente acoplada al flujo de información de

enrutamiento en la red, y la arquitectura de direccionamiento y encaminamiento se basa parcialmente en el establecimiento de estos flujos. Determinar flujos de distribución comienza con el proceso de análisis de flujo. Cuando se desarrollan los flujos en la especificación de flujo y el mapa de flujo, forman la base de flujos de enrutamiento (siendo lo que es enrutado a través de la red de los flujos de tráfico). El proceso de establecer flujos de enrutamiento en la red consiste en segmentar la red en áreas funcionales y grupos de trabajo, identificando los límites entre estas áreas, y luego formando las relaciones entre los límites y enrutamiento de flujos. Áreas funcionales (FA) son grupos dentro del sistema que comparten una función similar. Pueden ser grupos de usuarios (grupos de trabajo), aplicaciones, dispositivos o combinaciones de éstos, y pueden compartir tareas de puestos de trabajo similares, ubicaciones físicas o funciones dentro de la red (por ejemplo, encaminamiento de la espina dorsal). Grupos de trabajo (WG) son grupos de usuarios que tienen lugares comunes, las aplicaciones y requisitos, o que pertenecen a la misma organización.

Figura 6.12 un ejemplo de grupos de trabajo y áreas funcionales

El propósito de las áreas funcionales es simplificar la arquitectura de enrutamiento. Pueden cruzar fronteras físicas, como edificios, habitaciones y pisos. Un grupo de trabajo es similar a un área funcional, pero un nivel más bajo en la jerarquía. Considerar la figura 6.12. En esta figura hay varios grupos de trabajo, en este caso se basa en organizaciones dentro de una empresa. Se crean áreas funcionales: los científicos y grupos en el edificio C contabilidad, los dos grupos de trabajo de gestión en el edificio B, los grupos de científicos a través de los edificios A y C y la columna vertebral entre los edificios. Tenga en cuenta que las áreas funcionales están conectadas con routers.

6.4.2 Identificar y clasificar límites de enrutamiento

Los límites de distribución son separaciones físicas o lógicas de una red, basada en requisitos o administración de esta red. Fronteras físicas se pueden identificar por aislamiento LANs o zonas desmilitarizadas (DMZs); interfaces físicas en equipo de red; o seguridad física. Límites lógicos pueden identificarse por áreas funcionales, grupos de trabajo, dominios administrativos, tales como sistemas autónomos (culo) y enrutamiento dominios de administración. Sistemas autónomos tienen números asociados con ellos. Dominios de administración enrutamiento son a menudo el mismo culo pero pueden ser un subconjunto o un superconjunto de uno o más. Dominios de seguridad son lugares donde los dispositivos de seguridad se encuentran; utilizan espacio público fuera de los límites de seguridad y espacio de direcciones privado interior. El tipo de protocolo de enrutamiento utilizado para pasar información de enrutamiento a través de la frontera también puede distinguir límites. Hay dos tipos generales de protocolos de enrutamiento. Protocolos de gateway exterior(EGP) comunica información de enrutamiento (accesibilidad y métricas) sobre todo entre el culo. Protocolos de gateway interior (IGPs) comunicarán información de enrutamiento sobre todo dentro de un as La palabra "principalmente" se usa aquí, EGP puede utilizarse dentro de un AS, y IGPs pueden utilizarse entre el culo, aunque esto raramente se hace. Más adelante en este capítulo para que vemos formas EGP y IGP uso tanto dentro como entre el culo. Aquí utilizamos el término límite duro para describir un límite de enrutamiento donde EGP predominante se utiliza para pasar información de enrutamiento, mientras que un límite suave es un límite de enrutamiento donde se utilizan predominante IGPs. Límites duros se encuentran entre el culo, entre un AS y una red externa (que puede o puede no haber un asociado), o en separaciones bien definidas entre redes dentro de un AS (por ejemplo, en las interfaces entre organizaciones internas dentro de una empresa donde Existen diferentes dominios administrativos). Límites duros también se encuentran en interfaces para ISPs y se asocian con DMZs. figura 6.13 muestra un ejemplo de un límite duro. En este ejemplo se utiliza una red para separar una empresa a partir de un ISP. Una red para separar otras redes (proporcionar un almacenador intermediario entre ellos) a menudo se denomina un aislamiento LAN (iLAN). Otro término para el aislamiento de LAN es desmilitarizado

Figura 6.13 un ejemplo de un límite duro

zona, o DMZ. DMZ es una zona tampón entre dos facciones, en este caso las dos redes se separen. Se trata de un límite duro común y uno donde un EGP es probable que se utilice. Otro ejemplo es cuando una empresa quiere restringir las comunicaciones entre algunas organizaciones dentro de esa empresa (por ejemplo, desde el grupo de trabajo de contabilidad). Mientras que toda la organización está dentro de un AS, el límite entre el grupo de trabajo de contabilidad y el resto de la que es similar a una DMZ (podría considerarse un DMZ interna), así que esto también es un límite duro. En este caso se puede utiliza un EGP o IGP. Límites suaves suelen encontrarse dentro de un solo AS y generalmente se colocan en el cruce de FAs o gt, como en la figura 6.14. En esta cifra todas las interfaces entre las áreas funcionales son límites blandos. ¿Por qué nos nos interesa determinar límites de enrutamiento para nuestra red? Enrutamiento de límites son importantes porque son los puntos focales para los flujos de distribución. Recordar de

nuestros ejemplos que entre áreas funcionales y entre culo, límites duros y blandos se encuentran en los enrutadores, que agregan tráfico de enrutamiento. Éstos son también lugares donde las jerarquías se establecen en la red. Figura 6.15 muestra límites y flujos de enrutamiento de una red. Los flujos de distribución son flujos de información de enrutamiento entre áreas funcionales, así como entre el culo. Esta información de enrutamiento incluye inicialización enrutamiento, actualizaciones, transitorios y tráfico de fondo como Hola o keepalive mensajes. Enrutamiento límites y flujos son importantes para el desarrollo de la arquitectura y el diseño, debido a flujos de enrutamiento pueden ser manipulados en los límites de distribución.

Figura 6.14 un ejemplo de un límite suave

Figura 6.15 límites y flujos de enrutamiento en una red

6.4.3 Manipulación de enrutamiento fluye Manipular (i.e.,controlling) routingflowswithinthenetworkisvitaltotheproper funcionamiento y rendimiento de la red. La combinación de direccionamiento y de enrutamiento es importante en este proceso, localizar flujos de enrutamiento siempre que sea posible. Existen varias técnicas para manipular flujos de enrutamiento en los límites duros y suaves. Podemos suministrar una ruta predeterminada a través de nuestra red a través de propagación de ruta por defecto. Podemos utilizar filtrado de ruta para ocultar las rutas y agregación para simplificar la publicidad de la ruta. Podemos desarrollar relaciones interconexión entre redes o culo en los límites. También podemos desarrollar las políticas de distribución y aplicación de políticas. Una ruta por defecto es la ruta usada cuando no hay ninguna otra ruta para ese destino. Generalmente, se trata de la ruta con la mayor capacidad disponible para redes externas. Propagación de ruta por defecto es la técnica utilizada para informar a la red (o subredes o FAs) de la ruta por defecto; propagación se inicia en el punto de salida para la red. Filtrado de ruta es la técnica de aplicación de filtros de ruta para ocultar redes del resto de un AS, o para añadir, eliminar o modificar las rutas en la tabla de enrutamiento. Un filtro de ruta es una declaración, configuredinoneormorerouters, thatidentifiesoneormoreIPparameters (por ejemplo, un origen o destino dirección IP) y una acción (p. ej., gota o adelante) cuando el tráfico coincide

con estos parámetros. Filtrado de ruta se utiliza comúnmente en los límites de disco duros. Cuando se usa el IGP OSPF, filtrado de ruta no puede usarse para ocultar redes internas a la red OSPF. Esto es debido a la naturaleza del algoritmo de cálculo de la ruta en OSPF, que se discute más adelante en este capítulo. Agregación de ruta es la técnica de intercambio de información de enrutamiento entre culo, generalmente entre los proveedores de servicios de redes de tránsito y entre redes de cliente grande. Esta técnica se utiliza normalmente en los límites de disco duros y puede incluir información de la política. Históricamente, en Internet, mirando era el intercambio libre y abierto de rutas entre las redes de gran tránsito, pero cambios en la estructura y funcionamiento de Internet han modificado acuerdos de interconexión, por lo que ahora son un poco competitivos. Las políticas son abstracciones de alto nivel de la técnica de filtro de ruta descrita anteriormente. Como una ruta filtro toma una acción (por ejemplo, soltar, aceptar, modificar) el tráfico que coincide con uno o más parámetros (por ejemplo, direcciones del IP), una política tiene una acción similar sobre el tráfico que coincide con uno o más parámetros (por ejemplo, número o lista de números y métricas tiempo de día, costo). Las políticas permiten la una como para aceptar o denegar el tráfico, o modificar la información de enrutamiento entre culo, basándose en parámetros de alto nivel. Esto permite que las decisiones sobre el enrutamiento de tráfico sobre una base diferente métrica de ruta. Las políticas se aplican típicamente a través de límites duros y se utilizan en la actualidad con la EGP frontera gateway protocolo versión 4 (BGPv4), discutida más adelante en este capítulo. Por ejemplo, considere un grupo de culo interconectado, como en la figura 6.16. El enrutador 1 pares con Routers de 2 y 3. Routers de 2 y 3 aplicación una política de que el tráfico de AS1 debe tránsito AS2 para COMO4 y este tráfico no tránsito AS3. Para ilustrar estas técnicas de manipulación de la ruta, cada uno discutimos como se aplica el ejemplo en la figura 6.17. Los requisitos de enrutamiento para AS1 son los siguientes: 1.1. primaria para AS1 es a través de ISPa. 1.2. redundante a Internet (secundaria) para AS1 es ISPb.

Aplicación de la política Figura 6.16 entre sistemas autónomos

Figura 6.17 un ejemplo de técnicas de manipulación de la ruta

1.3. permitir que el AS2 tráfico tránsito (ir a) AS1 para obtener acceso redundante a Internet través de ISPa. 1.4. permitir la comunicación entre el grupo de trabajo WGa1 en AS1 y grupo de trabajo WGc1 en AS2 vía L7.

1.1 y 1.2 se resuelven mediante el establecimiento de acuerdos de peering con ISPa y ISPb. Este acuerdo especifica que ISPa debe propagar una ruta por defecto a AS1 con un menor coste de enrutamiento que ISPb. También, dentro de este acuerdo de peering, AS1 se anunciar una ruta agregada para sus subredes a ISPa con un costo menor que a ISPb. Mirando se realiza a través de un límite duro; por lo tanto, normalmente se logra con un EGP (por ejemplo, BGP4). Para 1.3, se desarrolla un tercer acuerdo de peering entre AS1 y AS2 por enlaces L1 y L2. AS1 acepta rutas agregadas de AS2 y pasa a través de AS1 a ISPa en un costo mayor que el costo de que AS2 utiliza para ISPb. El acuerdo de interconexión antes de que se modifica para permitir AS1 enviar rutas de AS2. ISPa se compromete a propagar rutas de AS2 a Internet a un costo más alto que a ISPb. Para 1.4, se establece un cuarto acuerdo de peering entre AS1 y AS2 vía L7. AS1 acepta anuncios de ruta de AS2/WGc1 para subredes dentro de este grupo de trabajo a través de enlace L7. Se aplica la ruta filtro para bloquear cualquier otro tráfico. Los resultados de la aplicación de técnicas de manipulación de la ruta a las necesidades de enrutamiento de AS1 se muestran en la figura 6.18.

Figura 6.18 los resultados de técnicas de manipulación ruta a AS1

Los requisitos de enrutamiento para

AS2 están la siguiente: 2.1. WorkgroupWGc5canonlycommunicatewithworkgroupWGc4vialinkL8. 2.2. permitir sólo el tráfico de AS1 que se recibe sobre enlace L7 y destinados al grupo de trabajo WGc1 a pasar; bloquear cualquier otro tráfico. 2.3. Deje espacio funcional FAc3 utilizar área funcional FAc4 como un camino alternativo a la Internet vía enlace L6. 2.4. no permita que el área funcional FAc2 utilizar área funcional FAc3 como un camino alternativo a la Internet vía enlace L8. 2.5. no publicidad de grupo de trabajo WGc2. 2.6. Grupo de trabajo WGc1 puede comunicarse solamente con AS1/WGa1 vía L7; denegar cualquier otro tráfico. 2.7. todas las demás áreas funcionales deben utilizar área funcional FAc1 como la ruta por defecto. 2.8. utilizar AS1 como un transitorio en cuanto a acceso redundante a Internet a través de ISPa. 2.9. uso ISPb como un acceso principal a Internet. Requisito 2.1 se soluciona aplicando vía filtración en ambos grupos de trabajo WGc5 y WGc4 a la fuerza esta encaminamiento a ocurrir y para evitar que otros grupos de trabajo utilizando enlace L8. 2.2, se establece un acuerdo de peering con AS1 y filtrado de ruta se aplica enlace L7. 2.3 se soluciona teniendo área funcional FAc4 propagar una ruta por defecto a través del enlace L6 a área funcional FAc3 con un costo mayor que el área funcional FAc3 está recibiendo de FAc1. En 2.4, ruta se aplica filtro funcional áreas FAc2 FAc3, como se hizo en el problema 2.1.

De 2.5, se aplican filtros de ruta en los enrutadores que conectan al grupo de trabajo WGc2, para evitar grupos de trabajo que se anuncia. En 2.6, se utiliza el filtrado de ruta, esta vez para comunicaciones vía L7. Tenga cuidado para no permitir que el grupo de trabajo WGc1 para usar enlace L7 como acceso a Internet. En 2.7, FAc1 se propaga una ruta por defecto a todas las áreas funcionales. Todas las áreas funcionales agregan anuncios de ruta en los límites blandos. Para 2.8, otro acuerdo de peering (acuerdo número 5) se establece con AS1 AS2 con AS1 como un tránsito a acceder ISPa ISPb falla de permitir. AS2 debe anunciar rutas agregadas a AS1 con un coste más alto que a ISPb. De 2.9, se establece un acuerdo de peering entre ISPb y AS2. AS2 se anuncian rutas agregadas a ISPb, ISPb anuncie un valor predeterminado a AS2 y ISPb propagará rutas de AS2 a Internet. Los resultados de la aplicación de técnicas de manipulación de la ruta a las necesidades de enrutamiento de AS2 se muestran en la figura 6.19.

Figura 6.19 los resultados de técnicas de manipulación ruta a AS2

6.5 Abordar estrategias de Durante el proceso de análisis de requisitos, es importante reunir información sobre las expectativas de crecimiento del dispositivo, para que puedan evitar tener que cambiar los esquemas de direccionamiento y configurar direcciones de dispositivo durante el ciclo de vida de la red. Aplicación de subredes, subnetting de longitud variable, atender clases, supernetting, direccionamiento privado y NAT y direccionamiento dinámico, queremos procurar que nuestras direcciones de red y máscaras escalará a los tamaños de las áreas que se asignarán a. También queremos establecer los grados de jerarquía en la red. Para escalar el direccionamiento de red, usaremos los números de • Áreas funcionales dentro de la red • Grupos de trabajo dentro de cada área funcional • Subredes dentro de cada grupo de trabajo • Número total de subredes (actuales y futuros) en las organización • Total números de

dispositivos (actuales y futuros) dentro de cada subred Mediante el establecimiento de la escala y jerarquías para nuestra red, estamos aplicando abordar no sólo todo el sistema, sino también a través de subredes, grupos de trabajo y áreas funcionales. La intención aquí es buscar a abordar desde muchas perspectivas, para que no pierdan el detalle de cualquier área en particular, ni dejar de ver el panorama general de la dirección. Mientras que cada una de las estrategias de tratamiento podría aplicarse a cualquier área de la red, hay áreas donde es más apropiado cada estrategia. Figura 6.20 muestra donde cada estrategia se aplica.

Figura 6.20 aplicar diversas estrategias de tratamiento

Abordar estrategias de

En la parte inferior de la jerarquía, donde se tratan los dispositivos y subredes, subnetting de longitud variable puede proporcionar la flexibilidad necesaria para asignar direcciones a una gran variedad de tamaños de dispositivo de red. En medio de la jerarquía, donde hay áreas funcionales y grupos de trabajo, subnetting es a menudo suficiente. En el extremo superior de la jerarquía, donde se encuentra toda la red (junto con interfaces más externas), utilizando la mascarilla natural para la dirección de red o aplicación de subredes es generalmente adecuado. Las jerarquías de longitud variable subnetting tanto internos como externos a la red, se muestran en la figura 6.21. En esta figura, un router hub conecta un número de routers del grupo de trabajo para un ISP. Este router hub puede interconectar redes hasta diez pero actualmente está conectado a sólo cinco. Cada grupo de trabajo router debe estar configurado para soportar cuatro redes, cada red tiene 10 a 20 dispositivos conectados a él. Se nos ha asignado el CIDR bloque 192.92.240.0/20, que se espera que resuma el router ISP. Podemos romper esta red en abordar áreas, basadas en el número de áreas funcionales, grupos de trabajo, redes y dispositivos. Esto nos ayudará a elegir dirección tamaños de mascarilla que son apropiados para la escala de nuestra red. En este ejemplo hay tres áreas a dirección. En primer lugar, los grupos de trabajo tienen cuatro redes con dispositivos de 10 a 20 por la red. Para esta área, podríamos asignar el bloque CIDR de un clase C por grupo de trabajo, con subredes con una máscara

Figura 6.21 ejemplo de Subnetting de longitud Variable

2 dispositivos/subred 30 dispositivos/subred Figura 6.22 aplica un ejemplo con Subnetting de longitud Variable

de 255.255.255.224 (o / 27), que apoyará hasta seis subredes con hasta 30 dispositivos por subred. La siguiente área es donde los routers del grupo de trabajo se conectan al router hub. Si direcciones necesitan ser asignado (si los routers no admiten enlaces sin numerar), podríamos subred una sola clase C del bloque CIDR con una mascara de 255.255.255.252 (o / 30), apoyo a 63 subredes con dos dispositivos por subred. Puesto que estas conexiones son punto a punto entre cada grupo de trabajo la fresadora y hub, sólo necesitamos tratar dos dispositivos por conexión. La tercera área es la conexión entre el router hub y el router del ISP. Aquí ofrecemos el anuncio Resumen 192.92.240.0/20. El resultado se muestra en la figura 6.22.

6.6 Estrategias de enrutamiento Esta sección presenta y describe a interiores populares y protocolos de enrutamiento exteriores. Sección 6.6.1 describe que protocolos son los mejores para que las circunstancias, y 6.6.2 describe cómo seleccionar los apropiados a utilizar dentro de cada red. Ahora que ya tenemos el marco para el encaminamiento desarrollado y algunas estrategias de direccionamiento, vamos a considerar algunas estrategias para la aplicación de protocolos de enrutamiento. Esta sección cubre las características de algunos protocolos de encaminamiento popular, criterios para hacer selecciones de estos protocolos y para aplicar y mezclar estos protocolos. Normalmente, cuando se evalúan los protocolos de enrutamiento, es en base a características que son algo distantes de la estructura general, como sus tiempos de convergencia; sus gastos de protocolo, en términos de capacidad (ancho de banda de arriba), la CPU y la utilización de la memoria; y su estabilidad. Mientras que estas son características importantes a considerar, a menudo es difícil relacionar directamente a la arquitectura o el diseño. Están, sin embargo, indirectamente relacionados con la arquitectura y el diseño a través de dos características comentamos varias veces en este libro: jerarquía y diversidad. Desde la perspectiva de elegir un protocolo de enrutamiento, la jerarquía y diversidad de la red ayudan a determinar la complejidad requerida y las características del Protocolo de enrutamiento. En la determinación de los grados de jerarquía y diversidad en la red, indirectamente estamos aplicando las características mencionadas a la red. Por ejemplo, tiempo de la convergencia para un protocolo de enrutamiento se relaciona directamente con el grado de diversidad en la red. Cuando se utiliza para proporcionar redundancia, un mayor grado de diversidad implica un requisito para predecible o garantizada (missioncritical) confiabilidad. Esto puede también ser explícitamente indicado como requisito a partir del análisis de requisitos. Diversidad aumenta en importancia, el protocolo de enrutamiento tendrá que converger rápidamente cuando se producen cambios en la topología de enrutamiento. Esto también indica una necesidad de estabilidad en la red enrutada. En redes distribuidas (que redes enrutadas generalmente son), jerarquía tiende a forzar la toma de decisiones (p. ej., decisiones de enrutamiento) el árbol. En el caso de protocolos de encaminamiento, esto puede requerir una abstracción de la jerarquía en el protocolo de enrutamiento, tales como la abstracción de área en OSPF. Podemos aplicar grados de jerarquía y diversidad de nuestra evaluación de protocolos de enrutamiento. Además, en la evaluación de los protocolos de enrutamiento para la red, asegúrese de que la red está segmentada en grupos de trabajo y áreas funcionales. Otros criterios a considerar en los protocolos de enrutamiento son la relativa complejidad de los protocolos, o su facilidad de uso y la interoperabilidad del protocolo. Estos criterios pueden ser más difíciles de evaluar subjetivamente, para que sean depende de cómo el proveedor implementa el protocolo de enrutamiento. Algunas de las muchas ventajas y desventajas en opciones de protocolo de enrutamiento son simplicidad y facilidad de uso frente a características y sofisticación y la interoperabilidad versus características específicas del proveedor. Algunos protocolos de enrutamiento son relativamente fáciles de configurar y mantener. RIP, por ejemplo, es prácticamente plug-and-play, siempre y cuando la red no es muy grande y no trate nada complejo. Fácil de usar protocolos tienden a tener pocas opciones o funciones y no pueden

escalar a altos grados de jerarquía o diversidad. Como protocolos de enrutamiento aumentan de características o escalabilidad, también llegan a ser más complejos, que requieren mayor pericia por parte del personal que operará la red. El protocolo de enrutamiento puede tener algunos parámetros que son ajustables, permitiendo que los operadores de red cambiar los valores de estos parámetros para optimizar el rendimiento del protocolo o características. Esto puede ser de gran ayuda para las redes que tienen tamaño extremo, único topología características o requisitos de desempeño de múltiples niveles, pero también requiere una gran cantidad de recursos de personal para la vigilancia y mantenimiento. La interoperabilidad es el apoyo de OAM & P, rendimiento y características a través de múltiples plataformas de proveedores. Para protocolos de encaminamiento, las normas son el comienzo hacia la interoperabilidad. Normas son necesarias, pero no suficiente, para la interoperabilidad del protocolo. No se supone que, cuando una implementación de una encaminamiento protocolo apoya o se basa en un estándar, compatible con todas las implementaciones de otros proveedores del mismo protocolo. De interoperabilidad, necesita saber que las implementaciones de proveedores va a implementar en la red, y luego o comprobar qué pruebas de interoperabilidad han sido realizadas (hay varios laboratorios de prueba que realizan dichas pruebas y divulgación de información al público) o prueba de interoperabilidad, en su propio entorno de prueba. A veces puede ser necesario o deseable abandonar interoperabilidad con el fin de obtener características o desempeño de un vendedor particular. Por ejemplo, podemos obtener una característica muy deseable con un protocolo de enrutamiento de específicos del proveedor, o un grado de apoyo del vendedor que supera con creces con un protocolo estándar. Sin embargo, mientras que hay momentos cuando pueden considerarse específicos de protocolos de enrutamiento, se debe siempre considerar con precaución. Si usted elige un proveedor específico (propietario), no estándar de enrutamiento de protocolo, corres el riesgo de convertirse en bloqueado en la utilización de dicho protocolo. Puede resultar costoso incluir o cambiar a un protocolo estándar, como las operaciones de la red personal puede tener para aprender este nuevo protocolo, incluyendo interacciones con el protocolo existente. Una vez asegurada en un protocolo de enrutamiento propietario, pueden verse obligados a seguir comprar y distribuir equipos de proveedor, aunque puede no ser óptima para la red.

6.6.1 Evaluación de protocolos de enrutamiento Ahora brevemente examinar y comparar algunas IGP y EGP popular: el protocolo de información de enrutamiento (RIP y RIPv2), el abrir ruta más corta primero (OSPF) protocolo de enrutamiento y la versión de protocolo de gateway de frontera 4 (BGPv4). También consideramos el uso limitado de las rutas estáticas en la red. No consideramos que ningún propietarios protocolos de enrutamiento en este libro. Rutas estáticas son rutas que se configuran manualmente, por personal de red o scripts, en dispositivos de red, y que no cambian hasta que manualmente eliminado o modificado. Como tal, no son un protocolo de enrutamiento sino que se consideran en este capítulo porque inciden la encaminamiento en una red. Muchas personas pasan por alto el uso de rutas estáticas, pero pueden ser útiles en algunas redes, sobre todo cuando no es necesario un protocolo de enrutamiento. Algunas de las desventajas a las rutas estáticas son que necesitan mantenimiento, y requieren recursos en routers. Esto puede ser importante con una gran cantidad de rutas estáticas.

Protocolos de enrutamiento son dinámicos. Aprenden sobre accesibilidad dentro y entre redes y actualizar la información periódicamente; por lo tanto, son necesarios cuando paths alternativos existen en la red (es decir, cuando hay cierto grado de diversidad). Cuando hay solamente una trayectoria dentro o fuera de un área, un protocolo de enrutamiento no puede adaptarse a los cambios en la topología. Una red stub es una red con sólo un camino en o fuera de él, como en la figura 6.23. Con redes stub, una ruta estática se puede aplicar entre el talón y la red a que está conectado. Las ventajas y desventajas en usar rutas estáticas es no tener que configurar y mantener un protocolo de enrutamiento versus tener que mantener las rutas estáticas. Puesto que una red stub tiene sólo un camino en o fuera de él, una ruta por defecto es todo lo que se necesita. Una ruta estática puede utilizarse para proporcionar esta opción por defecto. Rutas estáticas también pueden utilizarse para forzar la Frese a lo largo de un cierto camino. Puesto que no se utiliza un protocolo de enrutamiento, paths alternativos no aprendió ni utilizados, y así tráfico se ve obligado a utilizar la ruta estática. Hay veces cuando esto puede ser útil (por ejemplo, se

Figura 6.23 Stub Networks

veces se usa para mejorar la seguridad). Sin embargo, siempre debe ser usado con precaución. Cuando hay múltiples rutas dentro y fuera de una red, debe considerar un protocolo de enrutamiento. Populares protocolos de encaminamiento, como RIP, RIPv2 y OSPF, utilizan un algoritmo de enrutamiento de link-state o vector de distancia para determinar accesibilidad. En un algoritmo de enrutamiento vector distancia, cada router mantiene la "distancia" (una métrica a cada salto o conexión entre los routers de peso) entre sí mismo y los posibles destinos. Un vector (o lista) de estas distancias se calcula de la información de la distancia recibida de otros routers participantes en esa red. En un algoritmo de enrutamiento de link-state cada router aprende sobre sí mismo, sus vínculos con el salto siguiente routers (sus vecinos), y el estado de cada enlace. Esta información es con multidifusión a otros enrutadores de participantes, y todos los routers construcción su información de enrutamiento de la suma de estos multicasts. Para una excelente descripción de algoritmos de encaminamiento protocolo, vea interconexiones, segunda edición (la referencia completa aparece en la sección 6.1.1). RIP y RIPv2 son IGP que se basa en un algoritmo de enrutamiento vector distancia. Esto implica algunas características del comportamiento dinámico de redes RIP/RIPv2-routed. RIP y, en menor grado, RIPv2 son relativamente simples de implementar y mantener. RIP ha sido de alrededor durante mucho tiempo (más de 30 años), después de haber sido parte del conjunto de protocolo TCP/IP enviado con la mayoría de los sistemas UNIX, y hay mucha experiencia con redes RIP

enruta. Dada la simplicidad, longevidad y experiencia con RIP, interoperabilidad entre distintas versiones de RIP no debería ser un problema. Debido a la naturaleza del algoritmo de enrutamiento de vector de distancia utilizado en RIP y RIPv2, puede ser lentos para converger a una nueva topología de enrutamiento cuando se producen cambios en la red, donde "slow" es del orden de minutos. También pueden formar inestabilidades enrutamiento en redes con un alto grado de jerarquía o de diversidad, aunque ha habido varios mecanismos desarrollados para reducir al mínimo las probabilidades de que esto ocurra (por ejemplo, veneno inversa, sujeción temporizadores). Por estas razones, no son óptimas para las zonas que tienen altos grados de jerarquía o diversidad. RIP/RIPv2 se debe considerar cuando hay baja de mediana jerarquía y diversidad en la red. Grados de jerarquía y de diversidad se muestran en la figura 6.24. OSPF es un IGP basado en un algoritmo de estado de enlace. Como RIP/RIPv2, la elección del algoritmo de enrutamiento afecta las características del protocolo. En el caso de OSPF, el uso de un algoritmo de estado de enlace resulta en un tiempo de convergencia más rápido cuando se producen cambios en la topología de enrutamiento. Tiempos de convergencia pueden ser en el orden Jerarquía (nivel y grado de diversidad (grado de conectividad dentro de Agregación de las conexiones) un nivel)

Conexiones de Conexiones de 1 Nivel

No hay jerarquía

2 Niveles de

Baja jerarquía

Jerarquía medio 3 a 5 niveles Alta jerarquía > 5 niveles

1 Conexión 2 Conexiones, Altamente asimétrica 2 conexiones, Ligeramente asimétricos

No hay diversidad (Sin redundancia) Baja diversidad

Diversidad media 2 o más conexiones, simétricas (Sin balanceo de carga) Alta diversidad

Figura 6.24 grados de jerarquía y diversidad

de segundos, uno o dos órdenes de magnitud más rápidas que RIP/RIPv2. Para un área con alta jerarquía o diversidad, un tiempo de convergencia rápida puede ser la sola característica más importante de un protocolo de enrutamiento e indicaría el uso de OSPF. OSPF soporta también una abstracción de la zona, que ofrece una jerarquía de información de enrutamiento. La jerarquía OSPF conecta estas zonas a través de un área de red troncal, e información de enrutamiento es internalizado dentro de cada área. Esto reduce el tamaño de los flujos de información enrutamiento a través de la red OSPF. Además de la abstracción de la zona, OSPF soporta múltiples rutas de igual costo, permitiendo múltiples rutas a utilizarse para el mismo destino cuando sus costos OSPF son las mismas.

Hay ventajas y desventajas para tiempos de convergencia rápida y abstracción de la área de OSPF. Un trade-off es en complejidad. OSPF puede requerir una cantidad sustancial (en comparación con RIP) de configuración durante la instalación y posiblemente la configuración afinación para llegar a una topología de enrutamiento de estado de equilibrio optimizada. Hay más información para entender, controlar y utilizar en una red enrutada de OSPF. Esta información puede ser útil para aislar y solucionar problemas de enrutamiento, pero también requiere de las habilidades para utilizar esta información. Además, la interoperabilidad entre diferentes implementaciones de OSPF es menos cierto que con RIP. OSPF se debe considerar cuando hay alta jerarquía y diversidad en la red, como se muestra en la figura 6.24. BGPv4 (o BGP) es un trazado vectorial de EGP. Un algoritmo de vector de camino es similar a un algoritmo de vector de distancia, como el utilizado en RIP; sin embargo, opera en culo o listas de culo (caminos). Además, BGP puede utilizar las políticas para determinar acciones a seguir en los caminos. BGP intercambia información de enrutamiento mediante el establecimiento de interconexión conexiones mediante TCP con una lista definida por el usuario. BGP se utiliza para hacer cumplir las políticas de transporte de red para un AS, como permitir que todas las rutas de cierto en cuanto a utilizar este como una ruta de tránsito; rechazando todas las rutas que han sido aprendidas de algunos como; y sólo anunciar ciertas rutas de esto en cuanto a otros compañeros. La configuración de BGP depende de la complejidad de las definiciones de política. Una vez que estos se configuran, BGP se opere dentro de las políticas de una manera dinámica. BGP es el más adecuado como un inter-como (interdomain) enrutamiento de protocolo, aunque hay veces cuando se utiliza dentro de un as BGP funciona entre el culo, sin embargo, puede haber un número de routers (llamados enrutadores de borde) que se conectan a redes externas. Como tal, tiene que haber un mecanismo para enrutadores de borde de la misma en cuanto a comunicar la información de la ruta, por lo que se puede pasar al culo múltiples (ver figura 6.25). Por lo tanto, hay dos tipos de BGP: BGP externo y BGP interno. BGP externo (eBGP) es el modo de funcionamiento "normal" de BGP: pasar información entre el culo. BGP interno (iBGP) se utiliza para formar túneles entre routers de frontera dentro de un AS, con el fin de cruzar información de la ruta as. ¿Por qué es necesario? BGP comunica información y políticas que no son (como ahora) reconocidas por IGPs. Por lo tanto, si routers de frontera dentro de un AS se vieron obligados a usar un IGP para comunicarse (por ejemplo, OSPF), la ruta de acceso y política de información se perdería en la traducción entre BGP y OSPF. Por lo tanto, se utilizan túneles para que los routers de frontera no es necesario Traducir BGP para un IGP.

Figura 6.25 aplicación de BGP interno (iBGP) y BGP externo (eBGP)

6.6.2 Elección y aplicación de protocolos de enrutamiento Esta sección presenta algunas recomendaciones para elegir y aplicar protocolos de enrutamiento para la red. Fueron desarrollados para simplificar la aplicación de protocolos de enrutamiento siempre que sea posible. Estas recomendaciones son: 1. Minimizar el número de protocolos de encaminamiento utilizados en la red. Dos deben ser el máximo número de protocolos que permite, con sólo una IGP.

2. Comenzar con la estrategia de enrutamiento más simple y el mecanismo de enrutamiento/protocolo. 3. Como la complejidad en las rutas y opciones de enrutamiento protocolos aumento, reevaluar las decisiones anteriores. Minimizar el número de protocolos de encaminamiento es muy sencilla: no overcomplicate la arquitectura de enrutamiento mediante la aplicación de muchos protocolos de enrutamiento. Cuántos protocolos de enrutamiento son demasiados se basa en la capacidad de los clientes, específicamente responsables de OAM & P de la red, para apoyar los protocolos. No tiene sentido para el arquitecto y diseñar una red complicada que no se manejar por el personal de la red. Muchas redes se centran en una sola IGP dentro de su AS y un EGP comunicaciones externas. Sin embargo, como veremos, hay veces cuando múltiples IGPs dentro de un AS e incluso una mezcla de IGP y EGP junto dentro de un AS pueden trabajar, como las ventajas y desventajas en la complejidad y el soporte son bien entendidas. También queremos arrancar con la estrategia de enrutamiento más simple y más complejas estrategias cuando sea necesario. La estrategia más simple es utilizar rutas estáticas, y esto se consideraría en primer lugar, para las zonas de código auxiliar. Si no existen áreas stub en la red, o cuando se indica un protocolo de enrutamiento, entonces RIP o RIPv2 se debe considerar. Recuerda que RIP o RIPv2 es recomendable para baja a mediana diversidad y jerarquía de redes. Cuando la red se incrementa a un alto grado de jerarquía y diversidad, OSPF debe considerar. El enfoque es solicitar rutas estáticas en primer lugar, las zonas de código auxiliar, a continuación, RIP/RIPv2 al jerarquía de la red y la diversidad son bajos a medio y luego OSPF cuando la jerarquía de la red y la diversidad son altos. BGP se aplica cuando un EGP es necesaria en la red. Ya que estamos comenzando con el más simple mecanismo ruteo (rutas estáticas) y trabajando nuestro camino hasta mecanismos más complejos, generalmente comenzamos con los bordes externos de la red, donde la jerarquía y la diversidad son más bajos y trabajar nuestro camino hacia el centro o columna vertebral, de la red, donde la jerarquía y la diversidad son más altos (Figura 6.26).

Figura 6.26 una aplicación de ejemplo de rutas estáticas, IGP y EGP en una red

La idea es empezar simple y añadir un protocolo de enrutamiento más complejo sólo cuando sea necesario. Cuando es necesario un protocolo de enrutamiento más complejo, sin embargo, tenemos que reevaluar las opciones anteriores, no basta con añadir el protocolo a la red. Reevaluar las opciones anteriores, podemos decidir mantenerlos y simplemente añade el nuevo protocolo de enrutamiento a la red, o podemos decidir sustituir el protocolo de enrutamiento anterior con uno nuevo. La intención es mantener el número de protocolos de enrutamiento como mínimo y para evitar tener varias instancias del mismo protocolo de enrutamiento en diferentes áreas de la red. Con esto en mente, recomendación 3 puede ampliarse al estado: 3A. cuando previamente han elegido rutas estáticas y RIP/RIPv2 ha sido elegido como el protocolo de enrutamiento para otra área de la red, luego RIP/RIPv2 reemplaza rutas estáticas para las zonas donde se eligieron rutas estáticas. 3B. cuando RIP/RIPv2 previamente ha sido elegido, ha sido elegido OSPF como el protocolo de enrutamiento para otra área de la red y OSPF reemplaza RIP/RIPv2 para aquellas zonas donde RIP/RIPv2 fue elegido. 3c. BGP, cuando sea necesario para una red troncal, puede reemplazar OSPF o RIP/RIPv2 si había sido elegido previamente para la columna vertebral. Mientras que se recomienda mantener el número de protocolos de enrutamiento en la red a un mínimo, hay veces cuando los beneficios de tener más de un IGP pueden ser mayores que los costos de su mantenimiento y soporte. Cuando la jerarquía de la red y la diversidad son lo suficientemente altos como para justificar cambiar el protocolo de enrutamiento de RIP/RIPv2 a

OSPF, las áreas donde están asignadas ya RIP/RIPv2 o rutas estáticas son entonces reevaluadas. Puede haber áreas en OSPF es beneficioso u otras áreas donde no ofrece ningún beneficio adicional y puede aumentar los costos de soporte o mantenimiento. También puede haber ocasiones cuando es apropiada la aplicación dentro de la red, ya sea con RIPv2/RIP o OSPF, BGP. Aplicación de que BGP dentro de la red puede ser considerado cuando la red es tan grande que debe ser fragmentado en múltiples culo, o cuando las organizaciones dentro de la red administrativas, administración o seguridad autonomía. En tales casos los límites entre las organizaciones podrían ser tratados como un límite duro. Una cosa a tener en cuenta cuando se mezclan protocolos de enrutamiento es información para traducir entre protocolos de enrutamiento. Información tales como máscaras de red, parámetros de protocolo, políticas, o como información puede ser perdido o tergiversado al traducir entre protocolos de enrutamiento. Actualmente no hay ninguna traducción métrica estándar entre diferentes protocolos de enrutamiento. En la aplicación de protocolos de enrutamiento empezamos por evaluar los grados de jerarquía y diversidad de cada área funcional y teniendo en cuenta otros factores para esa área funcional o características de los protocolos de enrutamiento que se apliquen. Cuando se realiza un cambio en la elección del Protocolo de enrutamiento, tales como de rutas estáticas a RIP/RIPv2, de RIP/RIPv2 a OSPF, o de RIP/RIPv2/OSPF a BGP, necesitamos reevaluar las áreas funcionales donde protocolos de enrutamiento o rutas estáticas ya han sido elegidas. En general, RIP/RIPv2 reemplaza rutas estáticas y OSPF reemplaza a RIP/RIPv2. Pero recuerde que usted también puede considerar la combinación de los protocolos dentro de la red. Figura 6.27 ilustra el proceso de la aplicación de protocolos de enrutamiento. Áreas funcionales que contienen sólo redes de backbone deben considerarse, como son generalmente los más complejos. Por lo tanto es probable que la columna vertebral

Figura 6.27 una evaluación iterativa de protocolos de enrutamiento

las redes requieren los protocolos de enrutamiento más complejos. Esto es donde puede considerarse BGP. En general, para la red troncal: 1. Si todas las áreas funcionales están usando el mismo protocolo de enrutamiento, el protocolo se debe considerar primero para la columna vertebral. 2. Cuando se eligen varios protocolos de enrutamiento para la red, considere primero el protocolo más complejo para la columna vertebral. 3. Cuando la columna vertebral interconexiones de culo, o cuando las organizaciones requieren autonomía en interconexión a la red troncal, consideran BGP como el protocolo de enrutamiento para la columna vertebral. Las decisiones se convirtió en la elección y aplicación de protocolos de enrutamiento deben ser documentadas como parte de la arquitectura de direccionamiento y enrutamiento. Mostrando las decisiones para cada área de la red, como en figuras 6.26 y 6.27, es un comienzo hacia esta documentación.

Consideraciones sobre la arquitectura

6.7 Consideraciones sobre la arquitectura En el desarrollo nuestro direccionamiento y enrutamiento de arquitectura tenemos que evaluar los sistemas de relaciones internas y externas para esta arquitectura de componentes.

6.7.1 Relaciones internas Dependiendo del tipo de red se desarrolló, el candidato abordar y mecanismos para una arquitectura de componentes de la expedición puede ser muy diferente. Por ejemplo, una proveedor de servicios de red puede enfocarse en mecanismos como el supernetting CIDR, difunde, interconexión, enrutamiento y políticas Confederaciones, mientras que el foco de una red de empresas medianas sería más probable en las privadas y red traducción de direcciones, subredes, redes VLAN, conmutación y la elección y ubicaciones de protocolos de enrutamiento. Dos tipos de interacciones son predominantes dentro de esta arquitectura de componentes: ventajas y desventajas entre el direccionamiento y los mecanismos de reenvío y compensaciones dentro de abordar o expedición. Abordar y expedición de mecanismos influyen en la elección de protocolos de enrutamiento y donde se aplican. También forman una jerarquía de direccionamiento en el que la jerarquía de encaminamiento es overlaid. Un ejemplo de esto se muestra en la figura 6.28. Esta figura ilustra las interacciones dentro de la arquitectura de direccionamiento/expedición. Dentro de esta arquitectura, enrutamiento

Figura 6.28 un ejemplo de las interacciones dentro de la arquitectura de direccionamiento/enrutamiento

selección de protocolo, por sí sola o en combinación con el direccionamiento de la VLAN, determina la selección de ruta de acceso del ISP. Áreas de la red donde se aplican el direccionamiento dinámico de direccionamiento privado y mecanismos de traducción de dirección de red se impacto cómo enrutamiento voluntad (o no) siempre en esas áreas.

6.7.2 External Relationships Relaciones externas son compensaciones, dependencias y restricciones entre la arquitectura de direccionamiento/enrutamiento y cada una de las arquitecturas componente (administración de red, rendimiento, seguridad y otras arquitecturas de componentes que puede desarrollar). Hay relaciones externas comunes entre abordar / ruta y cada una de las arquitecturas de componentes, algunos de los cuales siguen aquí.

Interacciones entre abordar/enrutamiento y administración de redes. Abordar/routing se puede usar para configurar límites de administración de la red. Por ejemplo, límites de sistema autónomo (AS) indican donde un manejo dominio termina y otra comienza. Interacciones entre abordar/enrutamiento y rendimiento. Rendimiento se pueden acoplar estrechamente con direccionamiento/enrutamiento a través de mecanismos tales como MPLS, diferenciados y servicios integrados y RSVP. Sin embargo, cuando ruteo simplicidad del protocolo es una prioridad alta, rendimiento puede desacoplado de abordar/enrutamiento. Rendimiento también se puede acoplar con direccionamiento/enrutamiento mediante el uso de IPv6, que ofrece campos de información que pueden ser utilizados por los mecanismos de funcionamiento. Interacciones entre abordar/enrutamiento y seguridad. Mecanismos de seguridad a menudo son intrusivos como interceptar, inspeccionar y controlar el acceso a la red y tráfico. Como tal, puede afectar el comportamiento de enrutamiento de la red. Así como zonas o perímetros de seguridad límite de funcionamiento (desde el capítulo 8), ellos también limitados de enrutamiento. Traducción de direcciones de red (NAT) puede utilizarse para mejorar la seguridad, así como proporcionar espacio de direccionamiento privado para una red. Formando un límite entre espacios de direcciones públicas y privadas, con la traducción de direcciones entre estos espacios, se puede controlar más el acceso exterior a la red. Direccionamiento y enrutamiento pueden afectar a la seguridad en tres formas: 1. En términos de acceso a la red desde el exterior (firewalls, ocultar IP y NAT) Ejercicios

2. En las medidas de protección cómo se implementan en los servidores (por ejemplo, listas de control de acceso restringen el acceso basado en dirección IP y subred) 3. En su capacidad para trazar un ataque dentro del perímetro El uso de direccionamiento dinámico puede crear problemas en el seguimiento de eventos de red. Coloca algunos servicios (por ejemplo, servidores de Web de dirección pública) fuera del firewall o detrás del firewall (con sólo http permitida en el firewall) es una decisión importante. Contenedores no funcionará si el espacio de dirección IP es dinámico cuando desea controlar el acceso. También, permitir que sólo ciertos protocolos para comunicarse con un servidor desde dentro de un espacio de dirección bien conocida es una opción si la red está diseñada con esto en mente. Por último, direccionar correctamente paquetes hostiles es una opción con la arquitectura correcta.

6.8 Conclusions Direccionamiento y de enrutamiento proporcionan la funcionalidad básica para el reenvío del tráfico de administración del usuario y la red a través de la red. En el desarrollo de la arquitectura de direccionamiento / enrutamiento, es importante entender los conceptos fundamentales detrás de direccionamiento y enrutamiento y cómo se utilizan para dar jerarquía y diversidad en la red.

Este capítulo ofrece algunas nuevas formas de ver flujos de enrutamiento, enrutamiento y protocolos de enrutamiento. Utilizan grupos de trabajo y áreas funcionales para desarrollar límites duros y suaves para flujos de enrutamiento y aplica una serie de técnicas para manipular estos flujos. Estos mecanismos, junto con evaluar y elegir los protocolos de enrutamiento para la red, así como dónde aplicar las diversas estrategias de tratamiento, proporcionan una imagen del direccionamiento y enrutamiento de la red que le permitirá optimizar la expedición de flujos de tráfico a través de su red.

6.9 Exercises 1. Representan cada dirección en formato binario. ¿Cuál es la clase de cada dirección? a. 192.12.102.0 b. 10.20.30.100 c. 130.5.77.15 2. Para cada uno de los siguientes pares de longitud dirección/prefijo, dar su máscara natural (en notación decimal con puntos), su máscara de subred/supernet (también en notación decimal con puntos) y la gama de redes o subredes permitidas por la máscara. También describir todos los problemas y limitaciones con los pares de máscara de dirección, si los hubiere. 129.99.0.0/16 a. b. 136.178.0.0/22 c. 198.9.9.0/28 d. 192.92.240.0/20 e. 192.92.243/20 3. 136.178.0.0 de subred en 16 subredes. Mostrar las formas de cada subred, así como la máscara de subred binario y decimal con puntos. Consulte la figura 6.29 para ejercicios 4 a 7. 4. Donde están las áreas funcionales para este diseño de red? 5. Donde están los potenciales límites lógicos y físicos de este diseño de red? 6. Habida cuenta de la red Dirección 129.99.0.0/16, desarrollar un esquema de direccionamiento de longitud variable que mejor se adapta el diseño, con los siguientes números de usuarios:

COMO número de

Ubicación

Departamento de

Usuarios de

Legal

120

Contabilidad

370

HQ

1580

De la ingeniería

200

Toronto

Ventas

75

Boston

Ventas

110

Operations1

2150

Operations2

975

Ventas

575

Campus de Chicago Edificio 1 1 Campus de Chicago Edificio 2

2

3

Philadelphia

7. Está utilizando BGP-4 en la WAN entre AS1, AS2 y AS3. Describir en texto sin formato o como declaraciones de políticas de BGP-4 Cómo lo haría: a. AS3 permiten comunicarse con AS1, sino no AS2 para comunicarse con AS1 b. Permitir acceso Internet de AS3 y AS2 a través AS1 solamente entre 18:00 y 6 de la mañana EST cada noche Para detalles sobre la especificación BGP-4, consulte RFC 1771. Ejercicios

Diagrama de la figura 6.29 para los ejercicios 4 a 7

8. Considere lo siguiente. Usted es un ISP y tiene un grupo de direcciones (bloques CIDR) para asignar a sus clientes. Han asignado direcciones a un número de clientes en un bloque CIDR de 198.9.128.0/18 (equivalente al bloque de direcciones de clase C 198.9.128.0 a través de 198.9.191.0). Ahora uno de sus clientes quiere dejar de usar tu servicio de ISP y mover a otro ISP, manteniendo el/24 que había asignado a él (198.9.145.0/24). Estás en un dilema, como usted no puede tomar de nuevo esta dirección (abogados del cliente son mejores que el tuyo!), sin embargo, publicidad un CIDR bloque que contiene esa dirección parece romper las reglas de CIDR enrutamiento. a. Mostrar cómo enrutamiento basado en el partido más largo (más específico) le permite continuar este bloque CIDR de publicidad. b. Mostrar qué sucede con el tráfico de ex cliente si existe un error en el Internet y su ruta obtiene cayó. 9. Muchos diseños de red requieren acceso redundante a Internet, con la conexión de respaldo en modo de espera o con equilibrio de carga entre las dos conexiones. Utilizando BGP-4, delinear una estrategia para proporcionar una copia de seguridad conexión a Internet para los siguientes casos: a. La copia de seguridad de conexión a Internet se encuentra en modo de espera y puede hacerse operacional con un cambio en la configuración de enrutamiento

b. La copia de seguridad conexión a Internet está en pleno funcionamiento y no hay balanceo de carga entre las conexiones primarias y de respaldo

Esta página dejada intencionadamente en blanco

CAPÍTULO CONTENIDO 7.1 Objectives 7.1.1 Preparation 7.2 Background 7.3 Definición de gestión de red 7.3.1 Dispositivos de red y las características 7.4 Mecanismos de gestión de red 7.4.1 Mecanismos de vigilancia 7.4.2 Mecanismos de instrumentación 7.4.3 Mecanismos de configuración 7.5 Architectural Considerations 7.5.1 Gestión en banda y fuera-de-banda 7.5.2 Administración centralizada, distribuida y jerárquica 7.5.3 Escala gestión tráfico 7.5.4 Controles y equilibrios 7.5.5 Gestión de red gestión de datos 7.5.6 Selección de MIB 7.5.7 Integración en OSS 7.5.8 Relaciones internas

7.5.9 7.6 Conclusions 7.7 Exercises

Relaciones externas

298

7 Arquitectura de gestión de red Nuestra próxima arquitectura de componentes es para administración de redes. Gestión de red adecuada es fundamental para el éxito de cualquier red, y, como se verá, hay muchos factores a considerar en la provisión de gestión de la red.

7.1 Objectives En este capítulo usted aprenderá acerca de administración de redes y la arquitectura de gestión de red. Discutimos las diferentes funciones de administración de redes y los mecanismos utilizados para alcanzar estas funciones. Discutir y comparar un número de variaciones para la arquitectura de gestión de red, así como las relaciones internas y externas para la gestión de la red.

7.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con los protocolos de gestión de red (SNMP y CMIP/CMOT opcionalmente), las utilidades ping, Traceroute y TCPdump, información base (MIB) las estructuras de gestión y parámetros, y las funciones del sistema de ayuda (OSS). Algunas recomendaciones de fuentes de información incluyen: • Snmpv2, Snmpv3, Snmp y Rmon 1 y 2, por William Stallings, AddisonWesley, enero de 1999. • MIB de Snmp de comprensión, David Perkins y Evan McGinnis, Prentice Hall, diciembre de 1996. • Simple Network Management Protocol (SNMP), STD 0015,[2] por J. D. caso, Fedor M., M. L.

Schoffstall, C. Davin, mayo de 1990.

299

7.2 Background Administración de redes (NM) consiste en el conjunto de funciones de control, planificar, asignar, implementar, coordinar y controlar recursos de la red. Gestión de red solía ser una ocurrencia tardía en muchas arquitecturas de red. Por ejemplo, más diseños y arquitecturas de red se desarrollaron sin una reflexión acerca de los usuarios siendo malintencionado, que era generalmente cierto hasta hace unos años. Considerar los cambios que recientemente se han

hecho en seguridad SNMP. Hoy en día y en el futuro, las redes son un recurso cuya integridad debe ser medible y verificable. La arquitectura de gestión de red, como con las arquitecturas de componente, comienza con los requerimientos y análisis de flujo. Las áreas que deben abordarse durante el proceso de análisis incluyen: • Que protocolo de administración de red para aplicar • Aplicación de gestión de activos de alto nivel como parte de la arquitectura de gestión de red • Reconfiguración de la red a menudo para cumplir diversos requisitos de varios • La necesidad de controlar todo el sistema desde una sola ubicación o dispositivo • Pruebas de proveedor de servicios de cumplimiento de SLAs y políticas • La necesidad de monitoreo proactivo (descubrir los problemas de rendimiento antes de que los

usuarios, aplicaciones y dispositivos se ven afectados por ellos) • Requisitos para el acceso fuera de banda

Comenzamos este capítulo definiendo y caracterizando la gestión para una arquitectura de red y cómo planificar para monitoreo, configuración y solución de problemas de la red planificada. Luego examinamos los protocolos de gestión de red y requisitos de la instrumentación. Esto llevará a consideraciones para el desarrollo de la arquitectura de gestión de red.

7.3 Definición de gestión de red Administración de la red puede verse como una estructura formada por varias capas: • Gestión empresarial: la gestión de los aspectos del negocio de una red, por ejemplo, la gestión

de presupuestos y recursos, planificación y acuerdos. Definición de gestión de red

• Gestión de servicios: la gestión de prestación de servicios a los usuarios, por ejemplo,

proveedores de servicios de esto incluye la gestión de ancho de banda de acceso, almacenamiento de datos y entrega de aplicaciones. • Administración de redes: la gestión de todos los dispositivos de red en toda la red. • Elemento de gestión: la gestión de una colección de dispositivos de red similares, por ejemplo,

acceso a routers o sistemas de gestión de abonado.

• Gestión de elemento de red: la gestión de dispositivos de red individuales, por ejemplo, un solo

enrutador, el conmutador o el concentrador. Esta estructura es un enfoque de arriba hacia abajo, con el componente más abstracto (gestión empresarial) en la parte superior de la jerarquía y el componente más especificado, concreto (gestión de elemento de red) en la parte inferior de esta jerarquía. Esto se muestra en la figura 7.1. En consecuencia, como los componentes más abstractos, cambian las formas en que se aplican y medido (sus elementos de información). Así, en la parte inferior de esta jerarquía, (elemento de red, elemento, red) gestión es aplicada con variables y parámetros, mientras que en la parte superior de esta jerarquía (servicios, empresas), gestión se aplica en términos más abstractos, con las políticas. Esto es común a todos los componentes arquitectónicos, y encontraremos que las políticas se pueden utilizar para cada componente.

Figura 7.1 jerarquía de gestión de red

Gestión de red de la figura 7.2 se compone de elementos de manejo y transporte de manejo de datos

Gestión de red se puede dividir en dos funciones básicas: el transporte de información para la gestión en el sistema y la gestión de los elementos de información de NM (Figura 7.2). Estas funciones, como se muestra en la figura 7.2, consisten en una variedad de tareas, monitoreo, configuración, solución de problemas y planificación, que son realizados por los usuarios, administradores y personal de la red. Uno de los primeros desafíos en el desarrollo de una arquitectura de gestión de red es definir qué gestión de red realmente significa para las organizaciones que estarán realizando las tareas y recibir los servicios, es decir, los usuarios o clientes del sistema. Hay cuatro categorías de las tareas de administración de red que consideramos aquí, correspondientes a las cuatro tareas mencionadas anteriormente: • Monitoreo de notificación de eventos • Planificación y monitoreo para el análisis de tendencias • Configuración de parámetros de red

• Solución de problemas de la red

7.3.1 Dispositivos de red y las características Un dispositivo de red es un componente individual de la red que participa en uno o más de las capas de protocolo. Esto incluye dispositivos finales, routers, switches, DSU, hubs y NIC. Dispositivos de red tienen las características que se pueden medir. Se agrupan en end-to-end, por enlace, características por red o por elemento, como se muestra en la figura 7.3. Características de extremo a extremo son aquellos que pueden medirse a través de múltiples dispositivos de red en el camino de uno o más flujos de tráfico y puede ampliarse a través de

Figura 7.3 características de red pueden ser por elemento, por el enlace, por red o End-to-End

toda la red o entre dispositivos. Ejemplos de características de extremo a extremo para los dispositivos de red son la disponibilidad, capacidad, retraso, retardo variaciones (jitter), rendimiento, tasas de error y utilización de la red. Estas características pueden modificarse o añadidas, dependiendo de los tipos de tráfico en la red. Características por elemento y por-/ por-red de enlace son aquellas que son específicas del tipo de elemento o conexión entre elementos monitoreados. Estas características pueden ser utilizadas individualmente o pueden combinarse para un final precisos de forma característica. Ejemplos de características de al-link son propagación delay y enlace la utilización, mientras que ejemplos de características al elemento (para un enrutador IP) las tasas de reenvío de IP (por ejemplo, en los paquetes IP/segundo), tampón de utilización para el router y cualquier registro de fallos de autenticación. Gestión de redes y dispositivos de red incluye planificación de redes (por ejemplo, sitio de la célula para wireless), asignación de recursos inicial (por ejemplo, asignaciones de frecuencias o ancho de banda) y FCAPS desde el modelo de gestión de red de telecomunicaciones: culpa, gestión de configuración, contabilidad, desempeño y seguridad.

7.4 Mecanismos de gestión de red Hoy damos un vistazo a algunos de los mecanismos de gestión popular, incluyendo los protocolos de gestión de red. Actualmente existen dos principales protocolos de gestión de red: el protocolo de administración de red simple (SNMP) y el protocolo de información de gestión común (CMIP). CMIP incluye CMIP sobre TCP/IP (CMOT). Estos protocolos de gestión de red proporcionan el mecanismo para recuperar, cambiar y el transporte de datos de gestión de red en toda la red.

SNMP ha visto uso extenso y constituye la base para muchos sistemas de gestión de red comerciales y públicas. Proporciona servicios de recolección y configuración de los parámetros de dispositivos de red. Estos se realizan a través de la SNMP comandos obtener (para recoger el valor de un parámetro), get-next (para recoger el valor del parámetro siguiente en la lista) y set (para cambiar el valor de un parámetro ). También hay disposiciones para la notificación de eventos, mediante el uso de trampas. Una trampa es un umbral configurable por el usuario para un parámetro. Cuando se cruza este umbral, los valores de uno o más parámetros se envían a una ubicación especificada. Un beneficio de generación de la trampa es que puede interrumpirse la votación de determinados parámetros o alarga el intervalo de sondeo, y en su lugar se envía un aviso automático al sistema de gestión cuando ocurra un evento. Parámetros que son accesibles a través de SNMP se agrupan en bases de datos de gestión, o MIB. Parámetros pueden ser parte de el estándar MIB (MIB-II), otros MIB estándar (normalmente basado en un tipo de dispositivo de red, tecnología o protocolo), MIB monitoreo remoto o MIB específicos de la empresa, que tiene parámetros específicos de una producto de determinado proveedor. SNMP versión 3 (SNMPv3) se basa en las anteriores versiones de SNMP, proporcionando más seguridad en la autenticación, la capacidad de recuperar bloques de parámetros y la trampa de generación para la mayoría de los parámetros. Cuando SNMP se menciona en este libro, se refiere a SNMPv3 a menos que se indique lo contrario. CMIP/CMOT proporciona para la colección de parámetros y configuración, como SNMP, pero también permite más tipos de operaciones. Muchas características CMIP/CMOT, como objeto único en el mundo de nombres, clasificación de objetos, alarma informes, auditoría y administración de la prueba, pueden también ser proporcionados por SNMP MIB nuevo y herramientas para apoyar tales abstracciones. En general, SNMP es más simple de configurar y usar que CMIP/CMOT, ayudando a que sea ampliamente aceptado. Es generalmente más fácil a los dispositivos de red de instrumento con SNMP. SNMP se utiliza en el monitoreo, instrumentación y los mecanismos de configuración, todos los cuales se discuten a continuación.

7.4.1 Mecanismos de vigilancia Monitoreo es obtener valores de end-to-end, por vínculos y características por elemento. El proceso de supervisión implica recopilación de datos acerca de las características deseadas, procesamiento de algunos o todos estos datos, mostrar los datos (procesados) y un subconjunto de los datos de archiving. Normalmente se recogen datos a través de un sondeo (sondeo activamente dispositivos de red para gestión de datos) o control de proceso que implica un protocolo de administración de red (por ejemplo, SNMP) o el servicio de proxy. Como vemos más adelante en este capítulo, pueden utilizarse varias técnicas para obtener estos datos así como para asegurar que los datos sean actuales y válidos. Cuando los datos son recogidos, puede o no reflejar las características que deseamos controlar. Los valores de algunas de las características pueden ser derivado de los datos obtenidos, mientras que otros valores pueden ser modificados (por ejemplo, agrega, resta, promedio de tiempo). Este procesamiento de los datos.

Juegos de raw (sin procesar) y datos procesados tendrán que mostrarse. Existen diferentes tipos de pantallas que puede utilizar, incluyendo monitores estándar, muestra toda la pantalla o campo de visión y exhibiciones especiales. Junto con la elección de pantallas es también desee considerar cómo los datos se mostrarán al usuario, administrador o gerente. Existen varias técnicas para Mostrar datos, como registros y muestra textual, gráficos y tablas (estática y móviles) y alarmas. Algunos datos pueden ser abstraídos por símbolos, como la que muestra partes de la red como una nube. En algún momento durante este proceso algunos o todos los datos se guardan en un sistema o (semi-) permanente los medios de comunicación. Esta parte del proceso puede tener varios pasos, incluyendo el almacenamiento de información primario, la puesta en escena de datos por periodos cortos de tiempo, que podría estar en el servidor de administración de la red; almacenamiento de información secundario, la agregación de los datos de varios sitios de almacenamiento de información primario, en un servidor de almacenamiento de la red; y almacenamiento terciario, que es generalmente la más permanente y más lento — almacenamiento dentro de la red. Almacenamiento secundario y terciario se llaman a menudo archivos de almacenamiento de información. Figura 7.4 muestra cada parte de este proceso que ocurre en un dispositivo separado, pero todos se pueden combinar en un único dispositivo.

Figura 7.4 elementos del proceso de monitoreo

Monitoreo de notificación de eventos Un evento es algo que ocurre en la red que es digno de mención. Esto puede ser un problema o una falla en un dispositivo de red, a través de la red, o cuando una característica cruza un umbral. Sólo puede ser algo que es informativo para el usuario, administrador o gerente, como la notificación de una actualización. Eventos pueden notarse en un archivo de registro en una pantalla, o mediante la emisión de una alarma, según el nivel de prioridad del evento. Eventos son similares a los transitorios, que son de breve duración cambios en el comportamiento de la red. Los umbrales o límites pueden ser fijados en end-to-end, por enlace o características por elemento a corto plazo o inmediata notificación de eventos y transitorios. Esto se denomina análisis en tiempo real aquí. Figura 7.5 muestra un ejemplo de dicho control. Ping se utiliza para recopilar información de retardo ida y vuelta, que se presenta como un gráfico en el sistema de vigilancia. Un umbral de 100ms ha sido elegido para esta pantalla. Cuando se cruza este umbral, se dispara una alarma para notificar al administrador de red que puede existir un problema en la red.

Análisis en tiempo real requieren generalmente cortos intervalos la interrogación (períodos de tiempo entre sondeo activo de la red y dispositivos de red para gestión de datos), y hay una relación inversa entre el número de características y dispositivos de red consultados para el análisis en tiempo real versus la cantidad de recursos (capacidad, CPU, de memoria, almacenamiento de información) necesarios para dichos análisis. En algunos casos la cantidad de datos de red generados (y el tráfico resultante) por las periódicas encuestas de características múltiples en muchos dispositivos de red pueden

Figura 7.5 monitoreo de notificación de eventos

afectan al rendimiento global de la red. Por ejemplo, considere una red que tiene 100 dispositivos de red, donde cada elemento tiene un promedio de cuatro interfaces y cada interfaz se controla para las características de ocho. Esto añadiría hasta (dispositivos de red 100) ∗ (dispositivo de red o interfaces 4) ∗ (8 características/interfaz) = características 3200 Si cada una de las 3200 características genera un promedio de 8 bytes de datos y un estimado 60 bytes de overhead de protocolo, la cantidad de datos generados por la sesión de votación sería (características de 3200) ∗ (8 bytes + 60 bytes) = 2176 KB de tráfico, o 1,74 Mb de tráfico Si planeamos sondear con un intervalo de sondeo de 5 segundos, en el mejor esta 1,74 Mb de tráfico se extiende sobre 5 segundos, o 384 Kb por segundo. Sin embargo, es más probable, que la mayoría de los datos llegarán poco después de las encuestas se generan, por lo que el tráfico puede ser más parecido a un alza de 1,74 Mb por segundo después de que las urnas se producen. Para un período de un día, será la cantidad total de tráfico (1.75 mb/sondeo intervalo) ∗ (intervalos de interrogación 720/hora) ∗ (24 horas al día) = 30.2 Gb de tráfico

Y la cantidad de datos almacenados (intervalo de características/sondeo 3200) ∗ (8 bytes) ∗ (intervalos de interrogación 720/día) ∗ (24 horas/día) = 442 MB datos almacenados por día En el transcurso de un año, esto añadiría hasta más de 161 GB de datos. Y esto es una estimación conservadora para el entorno de la empresa de gama media. Planificación y monitoreo para el análisis de tendencias Las mismas características de end-to-end, por el vínculo y por el elemento utilizadas para el monitoreo de eventos también se pueden poner a trabajar en análisis de tendencias. Análisis de tendencias utiliza datos de gestión de red para determinar comportamientos de red a largo plazo o las tendencias. Esto es útil en la planificación para el crecimiento futuro de la red.

Figura 7.6 monitoreo de métricas y planificación

De esta recogida de datos continua, ininterrumpida, generalmente con largos intervalos de sondeo (minutos u horas en lugar de segundos), podemos comenzar mediante el establecimiento de líneas de tendencias y utilizar estas líneas de base para trazar el comportamiento de la tendencia. Esto se muestra en la figura 7.6. Esta figura muestra tendencias a largo plazo de disponibilidad, retraso y % de utilización. Encuestas para cada característica se guardan en la dirección de la red sobre una base regular y durante un largo período de tiempo (generalmente semanas o meses, pero a veces hasta años) las tendencias en estas características comienzan a surgir. En la figura 7.6, las tendencias al alza son claramente visibles demora y % de utilización.

7.4.2 Mecanismos de instrumentación Instrumentación es el conjunto de herramientas y utilidades necesarias para monitorear y probe la red para la gestión de datos. Mecanismos de instrumentación incluyen acceso a los datos de gestión de red mediante SNMP, control de herramientas y acceso directo. Instrumentación puede ser juntada con monitoreo, visualización, procesamiento. y almacenamiento de información para formar un sistema de gestión completo. SNMP (actualmente en la versión 3) proporciona acceso a información de gestión variables de base (MIB), las de MIB-II, otros MIB estándar (por ejemplo, MIB DS1), incluidas MIB específicos de empresa y otros MIB vigilancia (monitoreo remoto (RMON) e interruptor de control () SMON). SNMP es el método más común para acceder a datos de gestión de red. Hay varios disponibles en el mercado y monitoreo de paquetes de software disponibles que utilizan SNMP para el acceso a los datos disponibles al público.

Herramientas de monitoreo incluyen utilidades como ping, Traceroute y TCPdump, mientras que los mecanismos de acceso directo incluyen telnet, FTP, TFTP y conexiones a través de un puerto de consola. Un ejemplo de un conjunto básico de parámetros a monitorear puede ser desarrollado desde el estándar MIB-II. Los siguientes parámetros se pueden recoger en una base de interfaz: ifInOctets ifOutOctets ifInUcastPkts ifOutUcastPkts ifInNUcastPkts

Número de bytes recibidos Número de bytes enviados Número de paquetes de unidifusión recibidos Número de paquetes de unidifusión enviados Número de paquetes de multidifusión/difusión recibidos ifOutNUcastPkts Número de paquetes de multidifusión/difusión enviados ifInErrors Número de paquetes erróneos recibidos ifOutErrors Número de paquetes que no pudo ser enviado Estos parámetros se pueden utilizar para el monitoreo de eventos a corto plazo y análisis de tendencias a largo plazo de las tasas de rendimiento y error. Además, se puede recoger el siguiente parámetro para determinar la disponibilidad de: ifOperStatus estado de una interfaz (arriba, abajo, pruebas) Este parámetro podría utilizarse junto con herramientas como el ping de monitoreo para verificar la disponibilidad. En el desarrollo de la arquitectura de gestión de red, los requerimientos de instrumentación para cada tipo o clase de dispositivo de red, tales como elementos de transmisión (routers, switches, hubs), elementos de paso (por ejemplo, DSU, concentradores simples, simple puentes), y dispositivos pasivos como los que utilizan RMON, debe ser recogida. Una consideración de la arquitectura de gestión de red es para que la instrumentación sea precisa, confiable y simple. Hay un par de maneras de asegurar la exactitud en los instrumentos: pruebas y tomar medidas alternan. Si existe un entorno de laboratorio, se pueden replicar y probados algunas condiciones de la red limitada. Por ejemplo, generando cantidades conocidas de tráfico por dispositivos y generadores de tráfico y comparación de los resultados en los routers con los de los generadores de tráfico dispositivos pueden probar tipos de reenvío de paquetes en enrutadores. A veces se pueden comprobar parámetros de la red actual. Tomar medidas alternas del mismo parámetro en diferentes puntos de la red es una forma de verificar los parámetros. Seamos capaces de obtener datos de la capa de enlace de DSU, routers, y cambia la ruta de un flujo y comparando las distintas fuentes de datos, determinar si y cuando hay discrepancias en las mediciones de parámetros. De un sistema de gestión de red para que funcione correctamente, la instrumentación debe ser confiable. Un sistema de gestión de red es inútil si es lo primero cuando se producen problemas de red. Esto puede parecer obvio, pero algunos sistemas de gestión actuales son realmente robusto y confiable. Formas que fiabilidad puede mejorarse en la arquitectura son físicamente separando y replicación de los componentes de gestión. Al contar con varios sistemas de recolección, procesamiento, mostrar y almacenar datos de gestión para diferentes partes de la red y mediante la construcción de la jerarquía en los flujos de datos de gestión, la pérdida de un único

componente del sistema de gestión tendrá menos impacto en Administración de la red. Esto se cubre en más detalle más adelante en este capítulo.

7.4.3 Mecanismos de configuración Configuración de parámetros en un dispositivo de red para la operación y control de ese elemento. Mecanismos de configuración incluyen acceso directo a dispositivos, acceso remoto a los dispositivos y descarga los archivos de configuración (Figura 7.7): • Comandos de set de SNMP • Acceso Telnet e interfaz de línea de comandos (CLI) • Acceso a través de HTTP • Acceso a través de petición de objeto común broker arquitectura (CORBA) • uso de FTP/TFTP

para descargar los archivos de configuración

Figura 7.7 mecanismos de configuración de administración de redes

Como parte de este proceso, queremos generar un trabajo conjunto de end-to-end, por enlace y características por elemento y plan de arquitectura y diseño que las instalaciones para supervisar estas características en el corto y largo plazo intervalos de interrogación. Más adelante en este capítulo se desarrollan algunas pautas en donde instalaciones de monitoreo debe ser colocado en la red. Muchos dispositivos de red requieren cierto grado de configuración personal de la red. Para cada tipo o clase de dispositivo de red (por ejemplo, router de la marca X, switch Ethernet, etc.), queremos generar una tabla de parámetros de configuración, establecer los métodos para configurar estos parámetros y entender los efectos de los cambios de cada parámetro (cuando posible). Con el fin de gestionar adecuadamente una red, es importante entender cómo los parámetros de configuración afectan cada dispositivo de red. También necesitamos entender los efectos de problemas con dispositivos de red y cómo corregir esos problemas. Solución de problemas, que consiste en notificación de problemas, aislamiento, identificación y resolución, puede ser ayudado por conocer los modos de falla probable en la red, sus efectos y las posibles medidas para corregirlos.

Cabe señalar que, en la generación de un sistema de trabajo características, parámetros de configuración y modos de falla, vamos a través de una revisión detallada de cómo operará la red. El resultado es que entenderán mejor lo que sucederá en la red.

7.5 Architectural Considerations El proceso de gestión de red consiste en elegir qué características de cada tipo de dispositivo de red para controlar/administrar; instrumentar los dispositivos de red (o agregar dispositivos de recolección) para recoger todos los datos necesarios; procesamiento de estos datos para visualización, almacenamiento o presentación de informes; visualización de un subconjunto de los resultados; y almacenar o archivar algún subconjunto de los datos. Administración de la red afecta a todos los demás aspectos de la red. Ello está plasmado en el modelo FCAPS: • Administración de fallas • Gestión de la configuración • Gestión contable • Gestión del desempeño • Gestión de la seguridad

En este modelo, consiste en el manejo de fallas de procesamiento de eventos y alarmas (donde una alarma es un evento que desencadena una notificación en tiempo real al personal de la red); identificación de problemas, aislamiento, solución de problemas y resolución; y volviendo a la red a un estado operacional. Gestión de la configuración consiste en el ajuste de parámetros del sistema para la vuelta; aprovisionamiento de la red; configuración y sistema backups y restores; y bases de datos desarrollo y sistema operativo. Gestión contable consiste en controlar y administrar la utilización de los servicios abonados y factura de servicio. Gestión del desempeño consiste en la implementación de controles de desempeño, basados en la arquitectura de servicios IP; recogida de datos de rendimiento de red y el sistema; analizando estos datos de rendimiento; generar informes de corto y largo plazo de estos datos; y control de parámetros de rendimiento de red y sistema. Por último, gestión de la seguridad consiste en la implementación de controles de seguridad, basados en la arquitectura de seguridad; recopilar y analizar datos de seguridad; y generar seguridad informes y registros de datos. El modelo de gestión y proceso de gestión de red tanto aportar a la arquitectura de gestión de red. Con el conocimiento de qué dirección de la red significa para nuestra red, podemos considerar lo siguiente en la arquitectura:

• Gestión en banda y fuera-de-banda • Administración centralizada, distribuida y jerárquica • Escala tráfico de administración de red • Controles y equilibrios • Gestión de datos de gestión de red • Selección de MIB • Integración en OSS

7.5.1 Gestión en banda y fuera-de-banda Gestión dentro de banda se produce cuando los flujos de tráfico para la gestión de la red siguen las mismas rutas de la red como los flujos de tráfico para los usuarios y sus aplicaciones. Esto simplifica la arquitectura de gestión de red, en que las mismas rutas de red pueden utilizarse para ambos tipos de datos, y un camino por separado (y posiblemente la red) no son necesaria (Figura 7.8). Un compromiso con la gestión en banda es los datos de gestión flujos pueden ser afectados por los mismos problemas que afectan a los flujos de tráfico de usuario. Desde la parte de red

Figura 7.8 los flujos de tráfico para la gestión en banda

gestión es resolución de problemas en la red, esta función se ve negativamente afectada si los flujos de datos de gestión están retrasados o bloqueados. Así que cuando más se necesita gestión de la red, pueden no estar disponible. También, un objetivo primordial de la arquitectura de gestión de red debe ser capaz de hacer monitoreo de eventos cuando la red está bajo tensión, por ejemplo, cuando congestionadas de tráfico, sufre de problemas de configuración de hardware y software de red, o bajo una seguridad ataque. Gestión fuera de banda se produce cuando se dan diferentes caminos para flujos de datos de gestión de red y flujos de tráfico de usuario. Este tipo de gestión tiene la clara ventaja de permitir que el sistema de gestión que continúe vigilando la red en más eventos de la red, incluso cuando tales acontecimientos desactivar la red. Esto permite ver efectivamente en porciones de la red que son inalcanzables a través de vías normales (es decir, rutas de flujo de usuario datos). Gestión fuera de banda se proporciona generalmente a través de una red separada, como relevo de estructura o simple viejo teléfono (potes) acometidas. Figura 7.9 ilustra

Figura 7.9 los flujos de tráfico para administración fuera de banda

este punto. Una ventaja de tener una red separada es que características adicionales de seguridad pueden integrarse en esta red (red de administración). Puesto que esta red proporciona acceso a la mayoría o todos los dispositivos de la red, tener seguridad adicional aquí es importante. Otra ventaja es que la conexión fuera de banda puede ser utilizada para solucionar problemas y configurar los dispositivos de red que se encuentran en lugares remotos. Esto ahorra tiempo y recursos cuando es la red de datos de usuario y dispositivos de red remotos necesitan acceder. Cuando se planea la gestión fuera de banda, es necesario un método para comprobar y verificar su disponibilidad. Esto puede ser tan simple como va a utilizar la gestión fuera de banda sobre una base regular, independientemente de la necesidad. Esto ayudará a asegurar que problemas con la gestión fuera de banda detectados y resuelto mientras la red está todavía sana. Un compromiso con la gestión fuera de banda es el costo agregado y la complejidad de una red separada para la administración de la red. Una manera de reducir el gasto es proporcionar control fuera de banda en un nivel bajo de rendimiento, en relación con la red de datos de usuario. Por ejemplo, fuera de banda control puede lograrse mediante líneas telefónicas. Mientras que esto puede ser menos costoso que ofrece conexiones de red dedicada, requieren tiempo para configurar (por ejemplo, llamar) las conexiones fuera de banda y la capacidad de cada conexión pueden ser limitada. Para algunas redes una combinación de gestión en banda y fuera-de-banda es óptima (Figura 7.10). Generalmente esto se hace cuando el rendimiento de la red de datos de usuario se necesita para soportar flujos de datos de gestión de red (para monitoreo de la red operativa), pero es necesario la red independiente, fuera de banda cuando la red de datos de usuario está abajo.

Figura 7.10 flujos de una combinación de tráfico de administración en banda y fuera-de-banda

Algunas ventajas y desventajas de combinar la gestión en banda y fuera-de-banda son que aún se incurre en el costo de una red separada, y que todavía deben abordarse problemas de seguridad en la red de datos de usuario.

7.5.2 Centralizado, jerárquico y distribuido, Gestión Gestión centralizada se produce cuando todos los datos de gestión (por ejemplo, pings, SNMP encuestas/respuestas, Traceroute, etc.) irradian desde un único sistema de gestión (normalmente grande). Los flujos de datos de gestión se comportan entonces como los flujos de cliente – servidor discuten en el capítulo 4 como se muestra en la figura 7.8. La ventaja obvia a una administración centralizada es que se necesita solamente un sistema de gestión, simplificación de la arquitectura y reduciendo los costes (dependiendo de la elección del sistema de gestión). En administración centralizada el sistema de gestión tiene a menudo una variedad de herramientas de gestión asociadas con él. Algunas compensaciones a la administración centralizada son que el sistema de gestión es un punto único de falla, y que convergen todas las corrientes de gestión en la interfaz de red del sistema de gestión, potencialmente causando congestión o insuficiencia. Gestión distribuida se produce cuando hay múltiples componentes separados para el sistema de gestión, y estos componentes se colocan estratégicamente en toda la red, localizar el tráfico de gestión de red y gestión de distribución Dominios. En la figura 7.11 se utilizan múltiples sistemas de gestión de elemento local para distribuir las funciones de gestión a través de varios dominios.

Sistema de Figura 7.11 distribuido donde cada EMS Local tiene su propio dominio de gestión de la administración

Figura 7.12 distribuidos donde se distribuye el control de gestión

En la gestión distribuida los componentes proporcionan todas las funciones de administración (monitoreo, visualización, almacenamiento y procesamiento) o los componentes distribuidos son los dispositivos de monitoreo. Por ejemplo, Gestión distribuida puede adoptar la forma de tener múltiples sistemas de gestión de la red (por ejemplo, un sistema de gestión por campus o por dominio de administración, como se muestra en la figura 7.11), o un sistema de gestión único con varios nodos de supervisión, como en Figura 7.12. Ventajas a la gestión distribuida son que actúan los dispositivos de controles para localizar la recolección de datos, reduciendo la cantidad de datos de gestión que la red de tránsito. Puede también brindan monitoreo redundante, para que otros dispositivos de la supervisión de esa red pueden cubrir la pérdida de cualquier dispositivo de monitoreo individual. Un compromiso con la gestión distribuida es ese aumento de los costos con el número de aparatos de control o sistemas de gestión necesarios. Gestión jerárquica ocurre cuando las funciones de administración (monitoreo, visualización, almacenamiento y procesamiento) se separan y se colocan en dispositivos separados. Gestión es jerárquica, cuando se separan las funciones, se pueden considerar las capas que se comunican de una manera jerárquica cliente – servidor. (Véase el capítulo 4 para una discusión sobre los flujos jerárquicos cliente – servidor). Figura 7.13 muestra la estructura de un sistema de gestión jerárquica. En administración jerárquica, dispositivos de monitoreo localizados recogen datos de gestión y pasan estos datos directamente a los dispositivos de visualización y almacenamiento de información o a la supervisión de dispositivos para ser procesados. Cuando la gestión de datos se pasa a dispositivos de visualización y almacenamiento de información sin procesamiento, los dispositivos de controles actúan como lo hicieron en la gestión distribuida, localización de la recolección de datos y la reducción de la cantidad de datos de gestión que la red de tránsito.

Gestión jerárquica de la figura 7.13 separa en distintas funciones que se distribuyen en múltiples plataformas de gestión

Cuando la gestión de datos se procesa antes de ser enviado a pantalla y dispositivos de almacenamiento, entonces los dispositivos de controles actúan como filtros locales, enviar sólo los datos relevantes como (deltas en los valores de contador) o actualizaciones sobre eventos. Esto puede reducir considerablemente la cantidad de datos de administración en la red, que es especialmente importante si el seguimiento es en banda. Así, podemos tener control de dispositivos en lugares estratégicos a lo largo de la red, dispositivos locales electorales y los dispositivos de red, recolectar y procesar los datos de gestión y envío algunos o todos estos datos a los dispositivos de exhibición y almacenamiento. El número y ubicación de cada tipo de dispositivo depende del tamaño de la red, la cantidad de datos de administración que se recogen (discutido más adelante en este capítulo), y donde las pantallas y dispositivos de almacenamiento que se encuentra en la gestión de red arquitectura. Una ventaja a la gestión jerárquica es que cada componente puede hacerse redundante e independiente de los otros componentes. Por lo tanto, puede ser adaptado a las necesidades específicas de su red. En algunas redes puede ser preferible tener varios dispositivos de visualización, en otras redes de varios dispositivos de procesamiento o dispositivos de almacenamiento. Puesto que estos componentes son separados, los números de cada uno pueden determinarse individualmente. Un equilibrio en la gestión jerárquica es el costo, la complejidad y la sobrecarga de tener varios componentes de la gestión de la red.

7.5.3 Escala gestión tráfico Aquí se presentan algunas recomendaciones para ayudar a determinar y optimizar los requerimientos de capacidad de gestión de tráfico de red. Recomendación 1. Para un entorno de LAN, comience con un dispositivo de monitorización por subred IP. Para cada subred, estimar valores para las siguientes variables de tráfico: • El número de dispositivos y dispositivos de red a ser encuestados • Número promedio de interfaces por dispositivo

• El número de parámetros que deben recopilarse • La frecuencia de la interrogación (interrogación intervalo)

La combinación de estas variables da una estimación de la tasa de datos promedio para el tráfico de gestión por subred. Si esta tasa es mayor que aproximadamente 10% de la capacidad (tasa de línea) de la LAN, puede que desee considerar la reducción de tráfico de gestión generado, reduciendo una o más de las variables anteriores. Cuando la tasa promedio estimada es menos de 1% de la capacidad de la LAN, esto indica que es posible aumentar una o más de las variables anteriores. Para la mayoría de las tecnologías estándar de LAN (Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI), la tasa de gestión de tráfico debe estar dirigida en un 2% a un 5% de la capacidad de la LAN. A medida que aumenta la capacidad de la LAN, usted tendrá la capacidad más disponible para el tráfico de gestión de red y puede elegir aumentar una o más variables de tráfico (Figura 7.14). Cantidad de gestión Tecnología posibles acciones Tráfico/subred

Distribuir el control, reducir el número de parámetros encuestados, reducir el intervalo de sondeo

Consolidar el control, aumentar el número de parámetros encuestados, aumento del intervalo de sondeo

Figura 7.14 escala tráfico de administración de red

Recomendación 2. Para un entorno WAN, comience con un dispositivo de control por cada interfaz WAN-LAN. Se trata además de los dispositivos de monitoreo indicados en la recomendación 1. Sin embargo, si un dispositivo de vigilancia se encuentra en una subred de la LAN que es también el interfaz WAN, LAN, ese dispositivo puede utilizarse para recopilar datos para las LAN y WAN. Colocación de un dispositivo de vigilancia en cada interfaz WAN-LAN nos permite monitorear la red en cada lugar, así como medir, verificar y posiblemente garantizar servicios y requisitos de desempeño a través de la WAN.

7.5.4 Controles y equilibrios Frenos y contrapesos son métodos para duplicar las mediciones para verificar y validar los datos de gestión de red. Aunque la implementación de controles y equilibrios agrega esfuerzo para el proceso de gestión de red, es recomendable tener más de un método para colección red gestión de datos, particularmente para los datos considerados vitales para el buen funcionamiento de la red. Agente SNMP y MIB implementaciones son específicos de la implementación de proveedor y no están garantizadas para proporcionar los datos que son consistentes a través de todos los proveedores.

Objetivos de la realización de controles y equilibrios son localizar e identificar: • Errores de grabación o presentación de datos de gestión de red • Rollovers de contadores (por ejemplo, devolver un valor de contador a cero sin la debida

notificación) • Cambios en las variables de la MIB de la versión de un software a otro

Además, controles y equilibrios ayuda a normalizar los datos de gestión de red a través de múltiples proveedores, verificando los datos a través de mediciones de múltiples fuentes. Recogido datos deben verificarse para la exactitud de la gestión. Por ejemplo, cuando el sistema verificaba las variables SNMP para una interfaz, considere RMON así la interrogación para verificar estos datos. Considere el uso de un analizador de tráfico para verificar datos por varios períodos al azar. También puede ejecutar pruebas independientes con generadores de tráfico, los vendedores los dispositivos de red y dispositivos de recolección de datos, para verificar la exactitud de los datos recogidos.

7.5.5 Gestión de red gestión de datos Flujos de datos de gestión de red consisten en típicamente nombres de parámetros SNMP y valores y los resultados de consultas de utilidades como ping o Traceroute. Estos datos son generados por dispositivos de red y otros dispositivos de la red, transportados vía SNMP de dispositivos de control y posiblemente enviados a dispositivos de visualización y almacenamiento. Es importante la arquitectura de gestión de red que entender dónde y cómo los datos son generados, transportados y procesados, como esto nos ayudará a determinar donde se pueden colocar componentes de gestión de red en la red. Gestión de datos puede ser generados ya sea en un método (sin estado) consultas y respuestas, como con consultas SNMP o ping, o en respuesta a un conjunto prefijado de condiciones (stateful), como con SNMP trampas. Gran número de consultas SNMP debe ser repartida sobre un intervalo de tiempo (por ejemplo, el intervalo de sondeo), no sólo para evitar la congestión de la red, sino también para evitar sobrecargar los dispositivos de red y dispositivos de control con la transformación requerida para generar datos de gestión . Gestión de datos consiste en con frecuencia generados parámetros para notificación de eventos en tiempo real y menos con frecuencia generados (o necesarios) parámetros para la planificación y análisis de tendencias. Puede ser que los mismos parámetros se utilizan para ambos propósitos. Desde encuestas frecuentes pueden generar grandes cantidades de datos, almacenamiento de datos puede convertirse en un problema. A continuación se presentan algunas recomendaciones para manejar estos datos. Recomendación 1: almacenamiento Local versus archivo. Determinar qué datos de gestión son necesarias para mantener almacenados localmente y que datos pueden archivarse. Gestión de datos generalmente se mantiene localmente en caché donde puede fácilmente y rápidamente recuperar, para el análisis de eventos y análisis de tendencias a corto plazo (del orden de horas o días). Gestión de datos que no se utilizan para estos fines debe archivarse a almacenaje secundario o terciario, como archivos de cinta o almacenamiento fuera del sitio (Figura 7.15).

Figura 7.15 almacenamiento Local y el archivo de datos de gestión

Figura 7.16 selectiva en una base de datos separada

Recomendación 2: copia selectiva de datos. Cuando se utiliza un parámetro de gestión para la notificación de eventos y análisis de tendencias, considerar copia de cada iteración de th Nde ese parámetro en una ubicación de base de datos separada, donde el tamaño de la iteración N es suficientemente grande como para mantener el tamaño de Estos datos relativamente pequeños, sin embargo es lo suficientemente pequeño como para que los datos son útiles en análisis de tendencias. En la figura 7.16 SLA variables son consultadas con regularidad (cada variable emitidos por segundo), mientras que cada encuesta de th Nse guarda en almacenamiento a largo plazo (archivado). Dependiendo del ancho de banda y almacenamiento disponible para el tráfico de gestión de red, N puede variar de 102 a 105. Una relación inversa en copia selectiva de datos es que cada vez que los datos se copian, se corre el riesgo que algunos datos pueden perderse. Para ayudar a proteger contra este puede utilizar TCP para la transmisión de datos o enviar copias de datos a múltiples sistemas de archivo (por ejemplo, uno principal y uno redundante). Si hay indicios de que hay que hacer más análisis inmediato, ya sea un análisis de tendencia a corto plazo puede realizarse sobre los datos almacenados localmente (de recomendación 1), o el tamaño de la iteración que n puede acortarse temporalmente. Recomendación 3: migración de datos de. Al recoger datos de gestión de análisis de tendencias, datos pueden almacenarse locales para la gestión de dispositivos y luego descargados en almacenamiento/archivo al tráfico se espera que sea baja (por ejemplo, en la noche). En las

encuestas Figura 7.17 de la gestión de la red de datos se hacen en intervalos de cinco minutos y almacenados localmente. Estos datos entonces se descargan en archivo almacenamiento una vez o dos veces al día, generalmente cuando hay poco tráfico de usuario en la red (por ejemplo, en 2:00). Recomendación 4: metadatos. Metadatos de información adicional sobre los datos recogidos, como referencias a los tipos de datos, fecha y hora de cuándo fueron generados los datos y cualquier indicación que estos datos hace referencia a otros datos.

Migración de datos de la figura 7.17

Un sistema de gestión de archivo de datos debe proporcionar dicha información adicional respecto a los datos que se han recopilado.

7.5.6 Selección de MIB Selección de MIB significa determinar que MIB SNMP de utilizar y aplicar, así como que las variables en cada MIB son apropiadas para su red. Por ejemplo, esto puede ser un completo MIB (por ejemplo, MIB-II comúnmente se utiliza en su totalidad), un subconjunto de cada MIB requeridas de conformidad a las especificaciones que MIB (también conocido como un subconjunto de conformidad del MIB),[3] MIB específicos de la empresa (los parámetros de cada tipo de proveedor-elemento o elemento de red), o posiblemente un subconjunto de parámetros MIB que se definen para aplicar a tu red. Por ejemplo, se puede utilizar un subconjunto de los parámetros de supervisión de rendimiento de las Interfaces MIB (RFC 2863): ifInOctets, ifInErrors, ifInUcastPkts, ifOutOctets, ifOutErrors y ifOutUcastPkts. Este conjunto de seis parámetros es un punto de partida común para los parámetros de MIB. Estos parámetros pueden medirse generalmente en todas las interfaces para más dispositivos de red. Se pueden considerar variables MIB cayendo en los siguientes conjuntos: un conjunto que pertenece al estado de la red y un conjunto que es necesario monitorear y administrar esas cosas que la red debe soportar, incluyendo: • Servidor, usuario y parámetros de red • Parámetros de red que forman parte de SLAs, políticas y reconfiguración de la red

7.5.7 Integración en OSS

Cuando la red dispone de una interfaz a un sistema de soporte de operaciones (OSS), la arquitectura de gestión de red debe considerar cómo gestión debe integrarse con el OSS. La interfaz de administración de red OSS a menudo se denomina la interfaz hacia el norte, como en la dirección de servicio y gestión empresarial (ver sección 7.3). Esta interfaz hacia el norte es típicamente CORBA o SNMP (Figura 7.18).

7.5.8 Internal Relationships Las relaciones internas de la arquitectura de gestión de red comprenden las interacciones, dependencias, ventajas y desventajas y limitaciones entre los mecanismos de gestión de red. Es importante comprender estas relaciones, ya que son parte de un sistema complejo, no lineal y definen y describen el comportamiento de esta arquitectura. Interacciones Interacciones en la administración de la red pueden incluir las interacciones entre los componentes del sistema de gestión; entre el sistema de gestión de red y dispositivos de red; y entre el sistema de gestión y OSS. Si existen múltiples sistemas de gestión de red, o si el sistema de gestión de red es distribuida o jerárquico, habrá múltiples componentes

Figura 7.18 la integración de la gestión de la red con OSS

al sistema de gestión. La arquitectura de red debe incluir las ubicaciones potenciales para cada sistema componente o gestión, así como los flujos de datos de gestión entre los componentes o sistemas de gestión. Las interacciones aquí pueden ser en forma de preguntas/respuestas SNMP o CMIP/CMOT, CORBA, HTTP, transferencias de archivos o un protocolo propietario. Parte de la red de gestión inherente a cada dispositivo de red gestionada, en la forma de gestión de datos (por ejemplo, variables de la MIB) y el software que permite el acceso y transporte de datos de gestión en el sistema de gestión (por ejemplo, software de agente SNMP). Por lo tanto, las interacciones entre componentes de gestión de red (dispositivos de la supervisión particularmente) y dispositivos de red también se pueden considerar aquí. Podemos elegir a considerar todos los dispositivos de red gestionada, dependiendo de cuántos de ellos se espera que en la red; sin embargo, generalmente no consideramos todo administrados dispositivos en la red, como puede ser un gran número de ellos. Como ya comentamos en el análisis de flujo (capítulo 5), los dispositivos que son más propensos a ser considerados son aquellos que interactúan con varios usuarios, como servidores y equipo especializado. Las interacciones aquí están probables que en el formulario de consultas/respuestas SNMP o CMIP/CMOT. Si su entorno incluye una OSS, probablemente habrá algunas interacciones entre la dirección de red y la OSS, para a través de flujo de aprovisionamiento, gestión de servicios y control de inventarios. La arquitectura de gestión de red debe tener en cuenta donde se encuentra, el OSS que componentes del sistema de gestión de red interactúa con los OSS, y donde se ubicará en la red. Las interacciones aquí son propensos a usar CORBA, pero puede utilizar SNMP o HTTP (ver dependencias más abajo). Dependencias de

Dependencias dentro de la administración de la red pueden incluir dependencias en la capacidad y la fiabilidad de la red de flujos de datos de gestión; dependencia de la cantidad de almacenamiento de datos para gestión de datos; y la dependencia de la OSS para el requisito de interfaz hacia el norte. Administración de la red puede ser dependiente en el funcionamiento de la red subyacente para soporte de flujos de datos de gestión. En su sentido más básico, la red debe proporcionar capacidad suficiente por el importe estimado de la gestión de datos. Esta estimación puede obtenerse usando la información que discutimos en la sección 10.5 (en diseño de la red). Esto es particularmente importante cuando se centraliza la gestión de la red y todos los datos de gestión se agregan a la interfaz de sistema de gestión de red. Esto también puede ser una dependencia de servicios IP, discutido más adelante en esta sección. La cantidad de datos de gestión que se pueden almacenar es en parte una función de cuánto almacenamiento de información estarán disponible; así, administración de la red puede ser dependiente de la disponibilidad de almacenamiento de datos. Mientras que la interfaz de administración de red puede con una OSS, también puede ser dependiente de eso OSS para determinar la interfaz hacia el norte. Por ejemplo, algunos OSS requieren CORBA para su interfaz, que debe ser apoyada por la dirección de red. Esto puede también considerarse una restricción en la administración de la red. Ventajas y desventajas Ventajas y desventajas dentro de gestión de la red pueden incluir compensaciones entre gestión en banda y fuera de banda; y compromisos entre la administración centralizada, distribuida y jerárquica. Ventajas y desventajas entre gestión en banda y fuera-de-banda son los siguientes: • Gestión en banda es más barato y más sencillo de implementar que la gestión fuera de

banda; sin embargo, cuando los flujos de datos de gestión en banda, pueden afectadas por los mismos problemas que afectan a los flujos de tráfico de usuario. • Gestión fuera de banda es más caro y complejo de implementar que gestión en banda (ya que requiere las conexiones de red separado); sin embargo, puede permitir que el sistema de gestión que continúe vigilando la red en más eventos de la red, incluso cuando tales acontecimientos desactivar la red. Además, la gestión fuera de banda permite el acceso a dispositivos de red remota para solución de problemas y configuración, ahorrando el tiempo y esfuerzo de tener que estar físicamente presente en la ubicación remota. • Gestión fuera de banda, por definición, requiere que las conexiones de red separado. Esto puede

ser un beneficio, en que seguridad de la red separada puede ser enfocado en los requerimientos de flujos de datos de gestión, o puede ser un pasivo, en que se requiere para esta red seguridad adicional (con su cabeza y gastos asociados). • Cuando se combinan la gestión en banda y fuera-de-banda a, hay el costo y la complejidad de

gestión fuera de banda, así como los requisitos de seguridad adicionales. Sin embargo, la combinación permite (generalmente) higherperformance gestión en banda a ser usado para monitorear (que es la porción de alta capacidad de gestión de red), pero todavía permite una gestión fuera de banda ser utilizado en momentos críticos (por ejemplo, cuando los datos del usuario red [incluyendo rutas en banda] es hacia abajo). Ventajas y desventajas entre una administración centralizada, distribuida y jerárquica son los siguientes:

• En la administración centralizada se necesita solamente un sistema de gestión (todos los

componentes de gestión, así como otras herramientas, están en una plataforma de hardware), simplificación de la arquitectura y reduciendo los costes (dependiendo de la elección del sistema de gestión) sobre distribuyen o sistemas de gestión jerárquico, que tengan varios componentes separados. Sin embargo, la administración centralizada puede actuar como un punto único de falla; los flujos de datos de gestión se agregan en el interfaz de red del sistema de gestión, potencialmente causando congestión o insuficiencia. Distribuidos o gestión jerárquica puede evitar el punto central de falla y reducir puntos de congestión. • Los grados de distribución o de jerarquía en la gestión son una función de lo complejo y costoso

está dispuesto a permitir que el sistema de gestión a ser, y lo importante que es aislar dominios de gestión y proporcionar supervisión redundante. Los costos para la gestión distribuida o jerárquica aumentan con el número de aparatos de control o sistemas de gestión necesarios. Sin embargo, si usted está dispuesto a aceptar los altos costos de administración, puede proporcionar un sistema de gestión jerárquica totalmente redundante y flexible para la red. Limitaciones de Las limitaciones incluyen la interfaz hacia el norte de la dirección de la red a la OSS. Esta interfaz puede estar limitada por el requisito de la interface de la OSS. Puesto que el OSS potencialmente une varios servicio y componentes empresariales, sus requisitos de interfaz pueden ser forzados sobre gestión de la red. CORBA es a menudo necesario para esta interfaz hacia el norte.

7.5.9 External Relationships Relaciones externas constituyen compensaciones, dependencias y restricciones entre la arquitectura de gestión de red y cada una de las arquitecturas componente (direccionamiento/routing, rendimiento, seguridad y otras arquitecturas de componentes que puede desarrollar). Gestión de red debe ser una parte de todos los elementos arquitectónicos como necesitan todas o algunas de las capacidades de monitoreo, control y configuración que ofrece administración de red. Como tal, cada uno de los otros componentes interactuarán en cierto nivel con la administración de la red. Hay relaciones externas comunes entre la gestión de la red y cada una de las otras arquitecturas de componentes, algunos de los cuales se presentan a continuación. Las interacciones entre la dirección de red y direccionamiento/enrutamiento. Administración de la red depende de la arquitectura de abordar/enrutamiento por la ruta correcta de flujos de datos de gestión a través de la red. Si la gestión es en banda, entonces la ruta de los flujos de datos de gestión debe manipularse de la misma manera como el tráfico de usuario fluye y no requiere ningún tratamiento especial en la arquitectura. Sin embargo, si la gestión es fuera de banda, entonces la ruta de los flujos de datos de gestión deba considerar en la arquitectura. Gestión de red a menudo está limitado por la red o redes que se encuentran bajo administración común. Un dominio de administración se utiliza para describir un conjunto de redes bajo una administración común; sistema autónomo es otro término de uso frecuente. Así, el enrutamiento y direccionamiento arquitectura pueden definir el dominio de la gestión de la red, establecer los límites para la gestión de la red.

Si la gestión es fuera de banda, la red de gestión independiente puede requerir encaminamiento y abordar como parte de la arquitectura. Las interacciones entre la dirección de red y rendimiento. Administración de la red interactúa con la arquitectura de rendimiento a través de la recopilación de datos de rendimiento de red como pretende verificar el correcto funcionamiento de los mecanismos de funcionamiento. Esto puede ocurrir a través de un interfaz hacia el norte (descrito anteriormente) OSS o una base de datos de políticas para el funcionamiento. Rendimiento también depende de la administración de la red para proporcionar datos sobre el funcionamiento y la función de la red. Una relación inversa entre la dirección de red y rendimiento viene en cuanto recursos de la red (por ejemplo, capacidad) requiere de administración de redes, como esto puede afectar la capacidad de la red para soportar diferentes niveles de rendimiento. Esto es particularmente cierto cuando la administración es centralizada, gestión de flujos de datos en administración centralizada se agregan en el interfaz de red del sistema de gestión. Gestión de red puede depender del rendimiento de dos maneras: en primer lugar, cuando los mecanismos de funcionamiento apoyan tráfico del mejor-esfuerzo (según lo determinado en la especificación de flujo), parte de este tráfico del mejor-esfuerzo puede distribuirse en datos de gestión de la red corrientes; en segundo lugar, si se desea un servicio de mayor prioridad para flujos de datos de gestión de red, administración de la red será dependiente sobre los mecanismos de funcionamiento para proporcionar el apoyo necesario para este tipo de servicios. Cuando flujos de datos de gestión de red requieren de servicio de alta prioridad, gestión de la red puede ser dependiente de los mecanismos de actuación para funcionar correctamente. Las interacciones entre administración de redes y seguridad. Administración de redes depende de cierto nivel de seguridad para ser utilizado en entornos más operativos. Esto puede ser la seguridad en el nivel de protocolo (por ejemplo, seguridad SNMP) y para garantizar el acceso a dispositivos de red. Si la gestión es fuera de banda, la red independiente que apoya esta gestión debe estar asegurada. Administración de la red puede estar limitado por seguridad, si los mecanismos de seguridad no permiten datos de administración de red o acceso a través del perímetro de seguridad. Esto puede también considerarse un compromiso, cuando es posible reducir el nivel de seguridad para transporte de datos de acceso o de gestión a través del perímetro de seguridad. Por ejemplo, considere el uso de macetas para el acceso fuera de banda. Dicho acceso telefónico es inaceptable para muchas organizaciones, si no se toman las medidas de seguridad adicionales en cada línea de acceso (p. ej., dial-back, llaves de seguridad, etcetera).

7.6 Conclusions Mientras que la administración de la red puede parecer una simple función, es en realidad un complejo conjunto de funciones con características arquitectónicas interesantes. En este capítulo había descompuesta gestión de red en control, instrumentación y gestión y explorar cómo cada uno de estos puede lograrse dentro de la arquitectura de gestión de red. La esencia de la arquitectura de gestión de red está en entender qué desea controlar y administrar, determinar donde desea localizar cada función de administración de red y administrar los flujos de gestión de tráfico de red. Dependiendo de las características de la red

está desarrollando, tiene una amplia gama de soluciones arquitectónicas, de un sistema simple, single-plataforma con capacidades de monitoreo y gestión preconfigurados, para un sistema distribuido, jerárquico donde determinar y configurar sus capacidades de monitoreo y gestión. Basado en la información contenida en este capítulo, usted tiene la flexibilidad necesaria para crear una arquitectura de gestión de red adaptada a las necesidades de su cliente.

7.7 Exercises 1. ¿Cuáles son las capas de la administración de la red? Dar un ejemplo de gestión en cada capa (lo que se gestiona, cómo se gestiona). 2. ¿Cuáles son las diferencias entre supervisión de eventos y monitoreo para el análisis de tendencias y planificación? Dar un ejemplo de cada tipo para: a. monitoreo de la capacidad de un enlace WAN de OC - 3c b. monitoreo de la utilización de un enrutador IP

Ejercicios

3. ¿ Cual de las siguientes opciones son características de end-to-end? Características de la por-link/porred/perelement? a. Retardo de ida y vuelta entre un dispositivo de gestión de red y un servidor informático b. Porcentaje utilización de buffers en un enrutador IP c. Rendimiento máximo entre dos dispositivos (cliente y servidor) usando una aplicación cliente-servidor d. Tasa de error de bit (BER) de un enlace DS3 4. Para cada uno de lo SNMP comandos get, get-next, y set y usando la figura 7.19, describir lo que hace cada comando y dar un ejemplo de cómo se usa. 5. ¿Cuánta capacidad de almacenamiento de información se requiere para la siguiente configuración de gestión de la red (Figura 7.19)?

Sistema de gestión de elemento Todos los dispositivos emitidos cada 15 segundos 100% de los encuestados datos almacenados Almacenamiento para 2 años de continua interrogación

Dispositivos de usuario Dispositivos de red Dispositivos de usuario 1500 25 dispositivos de red 1 interfaz por dispositivo 4 interfaces por 6 variables por interfaz dispositivo 64 bytes por Variable 10 variables por interfaz 64 bytes por Variable Figura 7.19 dispositivos para problema de capacidad de almacenamiento de información

6. Esta red de la empresa actualmente cuenta con un sistema de gestión de red en el centro de operaciones de la red corporativa (NOC), situado en Minneapolis, que controla sólo los routers corporativos 13. Desarrollar una arquitectura de gestión de red que permite monitoreo de routers telefónico, manteniendo el tráfico de gestión

local en cada zona (Los Ángeles, Minneapolis y Washington, DC) y los routers así como de todos los dispositivos de usuario 190. 7. ¿ Cómo se generarían muchos datos de gestión en un enfoque de gestión centralizada, asumiendo recopilación de nueve contadores SNMP en todos los routers y la interrogación de ping ICMP de todos los dispositivos (red y usuario), con un intervalo de sondeo de 5 minutos? Cada contador SNMP y ping generan 64 bytes de datos. 8. Añadir dispositivos para la gestión de cada uno de lo sitios remotos (fuera del área de Minneapolis) fuera de banda desde el NOC de la empresa.

FIGURE 7.20 Diagram for Exercises 6 through 10

9. ¿Cómo la incorporación de la gestión fuera de banda entre el NOC corporativo y sitios remotos potencialmente afecta la seguridad de la red? 10. Recomendamos dos maneras de que la gestión de datos recogidos a través de contadores SNMP de cada uno de los routers se pudieron comprobar.

Esta página dejada intencionadamente en blanco

CAPÍTULO CONTENIDO 8.1 Objectives 8.1.1 Preparation 8.2 Background 8.3 Desarrollar objetivos de desempeño 8.4 Mecanismos de funcionamiento 8.4.1 Calidad de servicio 8.4.2 Priorización, gestión del tráfico, planificación y organización en cola 8.4.3 Acuerdos de nivel de servicio 8.4.4 Políticas de

8.5 Architectural Considerations 8.5.1 Evaluación de los mecanismos de funcionamiento de 8.5.2 Relaciones internas 8.5.3 Relaciones externas 8.6 Conclusions

8.7

Ejercicios

332

8 Arquitectura de rendimiento La arquitectura de rendimiento describe cómo usuario, aplicación, dispositivo y (vigente) requisitos de red para funcionamiento (capacidad de demora y RMA [confiabilidad, mantenibilidad y disponibilidad]) se cumplirá dentro de la red prevista. Desarrollo de requisitos de desempeño es una parte fundamental del proceso de análisis, y esta arquitectura de componentes es que son compatibles.

La arquitectura de rendimiento es el más nuevo de las arquitecturas de componente, y está evolucionando rápidamente para incluir muchos nuevos mecanismos para lograr el rendimiento de la red. Y, como se verá en este capítulo, esta arquitectura es altamente dependiente de las otras arquitecturas de componente para el éxito.

8.1 Objectives En este capítulo usted aprenderá sobre el qué rendimiento en una red, incluyendo descripciones de los mecanismos para lograr el rendimiento, cómo determinar las relaciones entre estos mecanismos y entre rendimiento y otros componentes arquitectónicos, y cómo desarrollar la arquitectura de rendimiento. También desarrollamos objetivos de rendimiento que guiarán el desarrollo de esta arquitectura.

8.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con los conceptos básicos y mecanismos de funcionamiento. Los conceptos básicos de rendimiento fueron discutidos en los capítulos 1, 2 y 3, y el acoplamiento de rendimiento para el trafico fluye en el capítulo 4 de este libro. Además, conceptos de arquitectura de red se presentaron en el capítulo 5. 333

Si necesita información adicional sobre mecanismos de funcionamiento y rendimiento de la red, algunas recomendaciones de fuentes incluyen: • Internet QoS: arquitecturas y mecanismos de calidad de servicio, por Zheng Wang, editores de

Morgan Kaufmann, marzo de 2001. • Diseño de calidad de soluciones de servicio para la empresa, Eric D. Siegel, John Wiley & Sons,

octubre de 1999.

• Red de alta velocidad: un enfoque sistemático a la comunicación de baja latencia de alto ancho

de banda, por James Sterbenz y toque de Joseph, John Wiley & Sons, abril de 2001. • Teoría de sistemas de colas, volumen 1, por Leonard Kleinrock, John Wiley & Sons, enero de

1975. • Solicitudes de comentarios de los servicios diferenciados (DiffServ) grupo de trabajo de la IETF y RFC 2474 2475 en particular. Ver www.ietf.org para estos RFCs.

8.2 Background Desempeño es el conjunto de niveles de capacidad, demoras y RMA en una red. Es generalmente deseable para optimizar estos niveles, para todos (usuario, aplicación y dispositivo) los flujos de tráfico en la red, o para uno o más conjuntos de flujos de tráfico, basados en grupos de usuarios, aplicaciones o dispositivos. En apoyo de rendimiento en la red, una arquitectura de rendimiento es el conjunto de mecanismos de actuación para configurar, operar, administrar, disposición y cuenta de recursos en la red que soportan flujos de tráfico. La muestra de arquitectura de rendimiento donde se aplican estos mecanismos dentro de la red y los sistemas de relaciones internas y externas entre ésta y otras arquitecturas de componentes. En este capítulo aprendemos acerca de recursos de la red y sobre los mecanismos de control y gestión. Una parte importante del desarrollo de esta arquitectura es determinar los objetivos de rendimiento de la red. Por ejemplo, el rendimiento se puede aplicar en: • mejorar el rendimiento general de la red (por ejemplo, para mejorar tiempos de respuesta y rendimiento a todos los usuarios, independientemente de donde están y qué hacen)

Desarrollar objetivos de desempeño

(Priorización, programación, Ajuste de rendimiento de línea de base Acondicionamiento del tráfico) (Ingeniería de tráfico) Figura 8.1 mecanismos generales para el funcionamiento

• Apoyo de un grupo en particular o grupos de usuarios o aplicaciones, tal vez nuevas o

aplicaciones previstas • Control de asignación de recursos para fines de contabilidad, facturación y gestión

Discutimos en desarrollo metas de rendimiento más adelante en la sección siguiente. En general, consiste en el desempeño de uno o más de los siguientes: control de entradas de tráfico a la red

(controles de ingreso y tasa); ajustar el rendimiento de la base de la red de tráfico o ingeniería de capacidad; control de todos o parte de la red de prestación de servicios específicos (priorización, programación y acondicionamiento de los flujos de tráfico); e implementación de un circuito de retroalimentación a los usuarios, aplicaciones, dispositivos y la administración para modificar los controles según sea necesario. Figura 8.1 muestra estos mecanismos generales.

8.3 Desarrollar objetivos de desempeño Para cada arquitectura de componentes es importante entender por qué esa función es necesario para esa red particular. Esto es especialmente importante para la arquitectura de rendimiento. El proceso de desarrollar objetivos para esto (o cualquier otro) componente arquitectura comienza durante análisis de requisitos y es más refinado durante el proceso de la arquitectura. Por lo tanto, los requisitos y especificaciones de flujo y mapas de aportar importante a este proceso. Mientras que el rendimiento es siempre deseable, debemos garantizar que los mecanismos de funcionamiento que incorporar en la arquitectura son necesarias y suficientes para lograr los objetivos de rendimiento para esa red. Por lo tanto, hacia el desarrollo de esta arquitectura, debemos responder las siguientes preguntas: 1. ¿Son los mecanismos de funcionamiento de esta red? 2. ¿Qué estamos intentando resolver, agregar, o diferenciar agregando mecanismos de rendimiento a esta red? 3. ¿Son mecanismos de rendimiento suficientes para esta red? En la determinación de mecanismos de funcionamiento son necesarios para una red, o no debemos ya tener la información necesaria para tomar una decisión de los requerimientos y análisis de flujo. Parte de la finalidad de determinar si los mecanismos de actuación son necesarios es evitar la aplicación de tales mecanismos sólo porque son interesantes o nuevos. Por ejemplo, puede ser tentador para implementar mecanismos de QoS en una red, incluso cuando no hay objetivos claros ni problemas para resolver. Cuando se indican los mecanismos de funcionamiento, usted debe empezar simple y trabajar hacia una arquitectura más compleja cuando se justifica. Simplicidad se puede lograr en esta arquitectura de implementación de mecanismos de rendimiento sólo en áreas seleccionadas de la red (por ejemplo, en el acceso o distribución [servidor] redes), o utilizando sólo uno o algunos mecanismos, o seleccionando sólo aquellos mecanismos que son fáciles de implementar, operar y mantener. Debe haber información en los requisitos y el análisis de flujo que pueden ayudar a determinar la necesidad de mecanismos de funcionamiento en una red. Algunos requisitos incluyen: • Claramente diferentes de los requisitos de rendimiento de red, por usuario, grupo, aplicación,

dispositivo o flujo • Requisitos para factura y cuenta de servicio de red

Cuando va a poner en práctica mecanismos de funcionamiento en una red, también deben determinar si es o no su cliente dispuesto a pagar los costos de tales mecanismos. Por ejemplo, ¿su cliente tiene un personal de red capaz de configurar, operar y mantener calidad de servicio, SLAs y políticas? ¿Si no, están dispuestos a pagar el costo de adquirir dicho personal, o subcontratar el rendimiento (y parte de administración de red)? El rendimiento no es una capacidad que es aplicada una vez y luego se olvida; requiere apoyo continuo. Si su cliente no está dispuesto a prestar ese apoyo, es mejor no aplicar estos mecanismos. Desarrollar objetivos de desempeño

La experiencia ha demostrado que cuando los mecanismos de funcionamiento son implementados y no apoyados, mantenidos o mantienen actualizados, rendimiento en la red realmente puede degradar a un punto en que sería mejor no tener algún mecanismo de funcionamiento en todos. Por lo tanto, determinar los requisitos de rendimiento y la disposición de su cliente para apoyar el funcionamiento, es fundamental para el desarrollo de esta arquitectura. Habiendo establecido una necesidad para el funcionamiento de la red, también deben determinar qué problemas de tu cliente está intentando resolver. Esto puede ser claramente en la definición de problema, desarrollada como parte del análisis de requisitos, o tal vez necesite investigar más lejos para responder a esta pregunta. Algunos problemas comunes que son tratadas por la arquitectura de rendimiento incluyen: • Mejorar el rendimiento general de una red • Mejorar el rendimiento para seleccionar usuarios, aplicaciones o dispositivos • Cambiar la red de un centro de costos a la rentabilidad • Combinar múltiples tipos de tráfico sobre una infraestructura de red común • Diferenciadoras (y posiblemente carga) clientes para varios niveles de servicio

Mejora el rendimiento general de una red es compatible con la red teniendo solo nivel de funcionamiento (determinada durante el análisis de requisitos). Cuando todos los usuarios, aplicaciones o dispositivos en una red requieren un nivel de rendimiento similar, su objetivo puede ser mejorar el rendimiento a todo el mundo. Cuando hay grupos de usuarios, aplicaciones y dispositivos que requieren mayor rendimiento que otros en la misma red, mecanismos de funcionamiento están obligados a ofrecer múltiples niveles de rendimiento. Tales redes tienen varios nivel rendimiento. Cuando se intenta cargar a clientes para el servicio, y posiblemente para generar ingresos para el servicio de red, mecanismos de funcionamiento son necesarios para proporcionar el marco contractual entre proveedor y suscriptores y para ofrecer un rendimiento de múltiples (y carga) niveles. También se necesitan mecanismos de rendimiento cuando un cliente quiere combinar varios tipos de flujo de tráfico. Esto es común cuando se consolidan varias redes. Por ejemplo, al construir una

nueva red de datos, su cliente puede migrar (eventualmente) servicios de voz y videos en esa red, eliminando la voz separada existente y redes de vídeo. Mecanismos de funcionamiento son necesarios para poder identificar los múltiples tipos de flujo de tráfico y provisión de los recursos de red necesarios para apoyar cada flujo. Finalmente, habiendo establecido la necesidad de funcionamiento en la red y determinar cuáles son los problemas se resolverán mediante la aplicación de mecanismos de funcionamiento, usted debe entonces determinar si estos mecanismos de funcionamiento son suficientes para esa red. ¿Se resuelven totalmente los problemas del cliente, o son sólo una solución parcial? Si son una solución parcial, ¿hay otros mecanismos que están disponibles, o estarán disponible dentro de su marco de tiempo del proyecto? Puede planea implementar mecanismos básicos de funcionamiento temprano en el proyecto y actualizar o agregar a esos mecanismos en varias etapas en el proyecto.

8.4 Mecanismos de funcionamiento Tal como se presenta en el último capítulo, mecanismos de rendimiento discutidos aquí son calidad de servicio, control de recursos (asignación de prioridades, gestión del tráfico, planificación y organización en cola), acuerdos de nivel de servicio y políticas. Estos mecanismos incorporan los mecanismos generales que se muestra en la sección anterior (Figura 8.1). Subconjuntos de estos mecanismos se utilizan generalmente juntos para formar un criterio amplio para proporcionar rendimiento single-tier y varios nivel en una red. Estos mecanismos proporcionan los medios para identificar los tipos de flujo de tráfico, medir sus características temporales y tomar diversas medidas para mejorar el rendimiento para flujos individuales, grupos de flujos, o para todos los flujos en la red.

8.4.1 Calidad de servicio Calidad de servicioo QoS, es determinar, establecer y actuando en los niveles de prioridad para los flujos de tráfico. QoS se asocia generalmente a la IP pero se utiliza aquí para definir una clase de mecanismos que disposición y aplicar niveles de prioridad en múltiples capas en la red. Esta clase incluye IP QoS (incluyendo MPLS), tipo de servicio (ToS), y Frame Relay comprometida (CIR) del índice de la información. En esta sección nos centramos en IP QoS. Para el tráfico basado en IP, existen dos tipos de QoS: servicios (DiffServ o DS) diferenciados y servicios (IntServ o IS), destinados a apoyar dos puntos de vista de servicio de red integrados. Se acerca a DiffServ QoS desde la perspectiva de agregación de los flujos de tráfico sobre una base por salto base en el comportamiento del tráfico, mientras IntServ acerca de QoS desde la perspectiva de apoyar los flujos de tráfico en un base individual, end-to-end. En DiffServ, paquetes IP están marcados en el tipo de byte de servicio (ToS) para IPv4 o en el octeto de la clase de tráfico en IPv6 para que reciban la correspondiente

rendimiento en cada dispositivo de red (o salto). DiffServ define un conjunto de valores (llamados diferenciados puntos de código de servicioso puntos de código DSCP) para las clases de flujos de tráfico, para ser utilizado por los mecanismos de control de recursos. Un concepto

importante de DiffServ es que se aplica a agregados de los flujos de tráfico (p. ej., compuesto de flujos), flujos de tráfico no individual. La razón principal para esto es para la escalabilidad (particularmente a través de Internet, pero también se podría aplicar en un entorno de grandes empresas). Si, en diseño y arquitectura de la red, todos los flujos que requieren servicio de prioridad fueron tratados individualmente, un equilibrio en la red sería la cantidad de recursos (por ejemplo, la memoria en los dispositivos de red) para almacenar y mantener información de estado para cada uno flujo individual en toda la red. Este requisito de recursos crece geométricamente con la red y por lo tanto no se escala bien. Por agregación de flujos en las clases de tráfico, almacenar y mantener información de estado se convierten en más sostenible. Información sobre el estado, o estado, es información sobre la configuración y el estado de flujos o de las conexiones. Ejemplos de direcciones (IP o MAC-layer), tiempo (duración de conexión de flujo, tiempo de inactividad) y las características temporales (tarifas de datos, pérdidas de paquetes). Hay tres clases de tráfico para DiffServ: esfuerzo, asegura la expedición (AF) y acelerado de reenvío (EF). Seguro y reenvío acelerado son las clases de tráfico recomendado: se basan en los tipos de rendimiento que requieren. Reenvío acelerado está dirigido generalmente hacia el tráfico que tiene requisitos de retardo (por ejemplo, en tiempo real o interactivo), mientras que la expedición asegurada puede utilizarse para el tráfico con requisitos de retardo y capacidad (por ejemplo, multimedia o tele servicios∗). Hay veces, sin embargo, cuando un flujo de tráfico debe tratarse individualmente. Servicios integrados define valores y mecanismos de asignación de recursos a los flujos a través de la ruta de extremo a extremo del flujo. IntServ está íntimamente ligada a la naturaleza del flujo de una red, mediante la colocación de importancia en el apoyo a un flujo en cada dispositivo de red en el camino de extremo a extremo de ese flujo. Recuerde nuestra discusión de análisis de flujo end-toend son definidos por usted y variará dependiendo de lo que está tratando de lograr. En la definición de donde-to-end se aplica para flujos particular (por ejemplo, flujos garantizados requisitos), están determinando dónde podrían aplicarse mecanismos como IntServ. Como se mencionó con DiffServ, sin embargo, las ventajas de IntServ vienen en un precio. IntServ necesita apoyo en los dispositivos de red a través del cual viaja el flujo, y requiere recursos (por ejemplo, memoria, procesamiento, ancho de banda) para cada flujo. Apoyo a través de múltiples redes implica la coordinación de servicio entre las redes. Y que requieren recursos para cada flujo significa que no se escala bien en zonas donde convergen las corrientes (por ejemplo, el área de la base de una red). IntServ también requiere un mecanismo para comunicar los requerimientos de flujo, así como la instalación y desmontaje de asignación de recursos, a través de dispositivos de red en el camino de extremo a extremo de un flujo. Dicha señalización es generalmente proporcionada por el protocolo de reserva de recursos (RSVP). Otros mecanismos de señalización, tales como con MPLS, también se están desarrollando para este propósito. RSVP es utilizado por los dispositivos de red (incluyendo dispositivos de usuario) a la solicitud específica a la calidad de los niveles de servicio de dispositivos de red en el camino de extremo a extremo de un flujo de tráfico. Éxito RSVP pide generalmente resultado en recursos se reservan en cada dispositivo de red a lo largo de este camino de end-to-end, junto con la información de estado sobre el servicio solicitado.

Por lo tanto, un mecanismo como éste se aplica mejor en un ambiente donde el administrador de red tiene el control de la ruta de extremo a extremo del flujo, como dentro de un entorno de empresa. Aunque IntServ es a menudo desestimada debido a su complejidad y problemas de escalabilidad, puede ser usado, pero sólo cuando hay un caso fuerte para ella (de los requisitos y especificaciones de flujo) y luego a una comprensión de lo que se requiere, en términos de red y recursos de personal, implementar y mantener. Una comparación de algunas de las funciones y características de DiffServ y IntServ se presentan en la figura 8.2. DiffServ y IntServ pueden aplicarse individualmente o en conjunto dentro de una red, y es posible combinar estos mecanismos en una variedad de maneras. Por ejemplo, DiffServ puede aplicarse en toda la red por sí mismo, o ambos pueden aplicarse en diferentes áreas de la red. Además, ambos mecanismos se pueden aplicar a las mismas áreas de la red, orientada a diferentes tipos de flujos. En este caso DiffServ es aplicado por primera vez a la red, y IntServ es entonces overlaid sobre él.

Función/característica

Servicios diferenciados (DiffServ)

Servicios integrados (IntServ)

Escalabilidad

Escalable a grandes empresas de redes de servicios

Limitadas a pequeñas o medianas empresas redes

Granularidad del Control

Tráfico agregado en clases

Por flujo o grupos de flujos de

Alcance de Control

Por dispositivo de red (por salto)

Todos los dispositivos en camino extremo-extremo del flujo de la red

Figura 8.2 comparación de DiffServ y IntServ

Si consideramos el modelo arquitectónico de acceso y núcleo/distribución (presentado en el capítulo 5) en el contexto de IP QoS, podemos empezar a ver donde podrían aplicar estos mecanismos. La porción de acceso de la red es donde fluye la mayoría es origen y año, por lo tanto, donde pueden ser (fácilmente) apoyaron individualmente. El núcleo de la red es donde se produce transporte a granel de los flujos, donde sería más conveniente agregarles. Por lo tanto, una forma de mirar a priorizar los flujos se presenta en la figura 8.3, donde agregación flujo través DiffServ se aplica en el centro, servicio por flujo a través de IntServ se aplica en el acceso y alguna traducción ocurre entre los dos en el límite entre el acceso y núcleo , posiblemente en la red de distribución. En esta figura IntServ se aplica como un mecanismo de end-to-end, donde se definen los puntos finales entre dispositivos dentro de cada acceso (y posiblemente su distribución de servir). Por lo tanto, está dirigido hacia esos flujos que permanecen dentro de una red de acceso o son de origen/año en la red de distribución. Por ejemplo, esto aplicaría para los flujos de cliente – servidor, donde los servidores se encuentran en la red de distribución. Para los flujos que atraviesan la red de núcleo, su comportamiento cambiaría de IntServ en las redes de acceso y distribución a DiffServ en la red de núcleo y estado se perderían como un compromiso para la escalabilidad. Sin embargo, los flujos que se mantienen en las redes de acceso o distribución todavía tendría los beneficios de la

IntServ en acceso / DiffServ en base / IntServ en acceso /

Figura 8.3 DiffServ y IntServ se apliquen en el modelo de base de distribución de acceso

IntServ. Y, importantemente, IntServ podría utilizarse para indicar la red de la base de recursos para una clase de tráfico. También es posible aplicar IntServ y DiffServ que trabajar simultáneamente en toda la red. En un caso como este (se muestra como los flujos de extremo a extremo en la figura 8.3), IntServ sería utilizada solamente un porcentaje relativamente pequeño de flujos y sería usado end-toend. DiffServ se utilizaría para otras corrientes priorizadas y pudieron agruparse en red el acceso o distribución. DiffServ y IntServ se utilizan para la priorización, programación y control de recursos se aplican a los flujos de tráfico. Cómo funcionan estos mecanismos se describe a continuación.

8.4.2 Priorización, gestión del tráfico, planificación, y cola Priorización, gestión del tráfico, planificación y cola estan en el corazón de proporcionando un rendimiento en una red. Una arquitectura de rendimiento puede incluir uno o más de estos mecanismos, junto con el QoS, SLA y políticas, para ofrecer a sus usuarios, aplicaciones, dispositivos y flujos de tráfico. Estos mecanismos se ponen en ejecución generalmente en dispositivos de red como routers y switches pero pueden aplicarse también a la red como hardware autónomo, como en dispositivos de administración de tráfico y control de admisión de específicos del proveedor. Asignación de prioridades Asignación de prioridades es el proceso de determinar que usuario, aplicación, dispositivo, flujo o conexión obtiene servicio delante de otros, o consigue un mayor nivel de servicio. Asignación de prioridades es necesario ya que habrá competencia entre los flujos de tráfico de recursos de la red. Con una cantidad limitada de recursos disponibles en cualquier red, priorización determina quién consigue recursos primero, y cuánto reciben. Establecimiento de prioridades comienza durante los requisitos y procesos de análisis de flujo. Niveles de prioridad para los usuarios, aplicaciones y dispositivos deben determinarse como parte del análisis de requerimientos y niveles de prioridad para los flujos de tráfico determinados durante el proceso de análisis de flujo. Por ejemplo, usted puede recordar (desde el capítulo 4) Cómo priorizar flujos basados en diversos parámetros, como el número de usuarios de apoyo y requisitos de funcionamiento. Para una arquitectura de rendimiento hay dos vistas de alto nivel de rendimiento: rendimiento de solo-grada, donde capacidad, demora o RMA está optimizado para todos los flujos de tráfico y varios nivel desempeño, en capacidad, demora o RMA está optimizado para uno o más grupos de flujos de tráfico, basados en grupos de usuarios, aplicaciones o dispositivos. Pueden tomar uno o ambos de estos puntos de vista para una arquitectura de red. Como con nuestro enfoque de IntServ y DiffServ, solo nivel rendimiento puede aplicarse en toda la red, con varios nivel de rendimiento en áreas seleccionadas, o como una adición al rendimiento de la solo-grada.

Estos dos puntos de vista de rendimiento implican que pueden existir varios niveles (niveles) de funcionamiento requerido por diferentes grupos de flujos de tráfico. Cuando hay varios niveles de requisitos de desempeño en una red (y por lo tanto múltiples grupos de flujos de tráfico), será necesario dar prioridad a estos flujos de tráfico. Ranking de priorización (determinar un nivel de prioridad) basado en la importancia y urgencia. Clasificación se puede aplicar a usuarios, aplicaciones, dispositivos, o su tráfico fluye. Un nivel de rango o prioridad indica la importancia o urgencia de ese usuario, aplicación, dispositivo o flujo, en relación con otros usuarios, aplicaciones, dispositivos o flujos de dicha red. Estos niveles de prioridad se determinan a menudo durante los requisitos y el análisis de flujo. El caso más básico o degenerado de priorización es cuando cada usuario, aplicación, dispositivo o flujo tiene el mismo nivel de prioridad. Tal es el caso en las redes de mejor esfuerzo. Cuando un usuario, aplicación, dispositivo, o flujo o grupos de éstos, requieren un rendimiento mayor que el caso general, entonces tienen más altos niveles de prioridad. Además, un individuo o grupo en el mismo nivel de prioridad que otros individuos o grupos pueden cambiar su nivel de prioridad debido a la urgencia de su trabajo. Por ejemplo, la mayoría de los usuarios en una red tiene un conjunto común de aplicaciones y dispositivos. A menudo utilizan un tipo similar de ordenador de sobremesa o portátil, con un tipo estándar de interfaz de red. Es probable que utilizan correo electrónico, Web, procesamiento de textos y otras aplicaciones comunes. Dichos usuarios pueden constituir un grupo de usuarios de la solo-grada rendimiento, todas con un nivel de prioridad único. Para algunas redes, esto es como obtiene la priorización y la arquitectura de rendimiento se centra en la optimización de rendimiento para todos los miembros de este grupo. Sin embargo, en algunos casos, incluso un grupo único, solo nivel rendimiento puede tener varios niveles de prioridades. En tal caso, pueden utilizarse niveles de prioridad para otorgar preferencia a las personas que no han utilizado la red para un período de tiempo, o que están dispuestos a pagar un premium de acceso preferente. Niveles de prioridad pueden ser basados en el tipo de protocolo (por ejemplo, TCP y UDP), el servicio o el número de puerto, dirección IP o MAC-layer, o por otra información encajados en el tráfico. Esta información puede ser mantenida en bases de datos y junto con las políticas y los SLAs (discutidos más adelante en este capítulo) como parte de la arquitectura de rendimiento. Niveles de prioridad son utilizados por dispositivos de red para ayudar a determinar si se permitirá flujos de tráfico en la red (control de admisión), programación de flujos de tráfico en la red y acondicionamiento de los flujos a través de la red. Gestión del tráfico Niveles de prioridad determinan la importancia relativa y la urgencia de los flujos de tráfico y cómo se manejará cada flujo de tráfico dentro de la red. Gestión del tráfico consiste en control de admisión y acondicionamiento del tráfico. Control de la admisión es la capacidad de negar el acceso a recursos de red. Acondicionado de tráfico es un conjunto de mecanismos que modifican (aumento o disminución) de rendimiento al tráfico fluye, como un precursor de la programación. Control de admisión utiliza niveles de prioridad para cambiar el comportamiento de acceso a la red. En una red de mejor esfuerzo sin control de la admisión, acceso a la red es democrático en que todos los flujos de tráfico tienen (más o menos) igual oportunidad de obtener recursos de la red. Con control de la admisión, sin embargo, acceso permitido, denegado, o a veces retrasado, basado en la prioridad relativa de que el tráfico.

Un ejemplo de esto es asignar mayor prioridad a los flujos de tráfico en tiempo real, como voz y video. En este caso los flujos de tráfico de vídeo y voz se dan acceso antes de otros flujos de tráfico. Cuando completamente se utilizan recursos de la red dedicados a estos flujos, más flujos se negaron (bloqueado). Control de la admisión se aplica más a menudo en zonas de acceso. Para entender el tráfico acondicionado funciones, vamos a seguir los flujos de tráfico a través de un dispositivo de red que implementa el acondicionamiento del tráfico. Como los flujos de tráfico entran un dispositivo de red, debe haber un mecanismo para identificar flujos y distinguir entre flujos. Clasificación es la capacidad para identificar los flujos de tráfico. El clasificador se ve en varias partes del paquete IP, como direcciones de origen y de destino, números de puerto o tipos de protocolo. Además, el clasificador puede parecer más profunda en un paquete la información necesaria. Por ejemplo, voz sobre IP (VoIP) flujos pueden determinarse mirando para protocolo de iniciación de sesión (SIP) identificadores (RFC 3261) dentro de los paquetes de señalización. A identificar los flujos de tráfico que son importantes para esa red, paquetes dentro de estos flujos pueden ser marcadoso etiquetados con un nivel de prioridad. Ejemplos de marca incluyen etiquetado paquetes con puntos de código de DiffServ (DSCP) para best-effort (BE), asegurados la expedición (AF) y niveles de prioridad (EF) de reenvío acelerado. Una vez que los flujos de tráfico han sido clasificados, pueden medir para determinar sus niveles de rendimiento. Medición mide las características de desempeño temporal de un flujo de tráfico, incluidas las tasas de tráfico y tamaños de ráfaga. Características de rendimiento se miden periódicamente y en comparación con los límites de rendimiento esperados, que pueden ser de SLAs o políticas. Medición es más a menudo una capacidad proporcionada en dispositivos de red (por ejemplo, enrutadores y conmutadores) como parte de su aplicación de rendimiento, pero también se puede aplicar como un dispositivo de red independiente (algunos dispositivos de administración de red pueden proporcionar soporte de medición, para ejemplo). Por ejemplo, un flujo de tráfico se puede medir durante un período de 1 segundo. Cada segundo, la tasa de datos máxima para ese flujo es comparada con un límite de capacidad de 1,5 Mb/s, que fue la entrada en el dispositivo de red de un SLA se convirtió para ése flujo de tráfico. Medición de un flujo de tráfico puede determinar si es o no un flujo dentro de los límites de funcionamiento (Figura 8.4). Conforme el tráfico es dentro de los límites de rendimiento; no conforme el tráfico está fuera de límites de rendimiento. Por lo general, no se toman medidas sobre el tráfico conforme. Conforme tráfico es reenviado a la cola de salida apropiado (según lo determinado por su nivel de prioridad) y programado para la transmisión en la red. Cuando el tráfico es no conforme, sin embargo (lo que indica que es superior a las especificaciones de un SLA), está sujeto a formar o se descartan. Formar está retrasando el tráfico para cambiar una característica de rendimiento, mientras que cae es descartar tráfico. Tráfico disconformes también puede estar marcado, con ninguna otra acción tomada. Esto se hace para que pueden elegir los dispositivos de red aguas arriba (los que recibieron este flujo de tráfico) dar forma o este tráfico si es necesario. Para forma de tráfico no conformes, se puede enviar a una cola de shaper donde retrasa se agrega antes de que se transmite en la red. Retrasando el tráfico, una cola de shaper cambia el rendimiento de ese flujo de tráfico. Considerar un SLA para un flujo de tráfico que especifica una tasa máxima de 1.5 Mb/s. (Mb/s se muestra como MBits/segundo en la siguiente discusión de consistencia en las unidades, en la práctica, la tasa se muestra generalmente como Kb/s, Mb/s o Gb/s). Un metro mide ese flujo de tráfico y calcula una tasa de:

200 paquetes/segundo byte de 8 bits/de 1500 bytes paquetes∗ =/de 24 MBits segundo

Figura 8.4 medición de tráfico en un dispositivo de red

Esto se compara con la especificación de SLA (1.5MBits / segundo) y encontrado para ser no conformes. Paquetes posteriores luego se reenvían a una cola de shaper, donde se demoran un promedio de 10ms. Como resultado, solo 100 paquetes pueden transmitirse por segundo y la velocidad de ese flujo de tráfico se convierte en: paquetes de 100/segundo byte de 8 bits/de 1500 bytes paquetes∗ =/de 12 MBits segundo Formación continúa ya sea para un período específico de tiempo o hasta que el flujo de tráfico se conforme otra vez. La acción más grave que puede adoptarse en tráfico es caer, o descartar, paquetes. Esto se hace cuando un flujo de tráfico serio es superior a su límite de rendimiento, o cuando el dispositivo de red está congestionado hasta el punto donde es necesario dejar caer los paquetes. Funciones de acondicionado de tráfico se muestran en la figura 8.5. Programación Una vez que el tráfico ha sido priorizado y acondicionado, se reenvía a uno o más salida de colas para la transmisión en la red. Planificación es el mecanismo que determina el orden en que tráfico se procesa para su transmisión. Programación utiliza niveles de prioridad para determinar qué flujos de tráfico consiguen procesados primero y más a menudo. Programación se aplica a los dispositivos de red a través de una red. En la mayoría de los dispositivos de red, como switches y routers, programación se proporciona a través de la dirección de la red, o como parte de la implementación de QoS en ese dispositivo. Programación puede ser propietaria (específica de la empresa) o basado en estándares. Algunos algoritmos de programación estándar comúnmente usados incluyen cola equitativa ponderada (WFQ) y cola basadas en clases (CBQ). Estos algoritmos proporcionan cierto grado de equidad en la cola permitiendo niveles de prioridad relativa (pesos). La combinación de QoS, priorización, gestión del tráfico y programación proporciona un amplio conjunto de mecanismos que pueden aplicarse a través de una red

Figura 8.5 tráfico acondicionado funciones

Programación de QoS, priorización, gestión del tráfico, Figura 8.6 Ley de mecanismos de rendimiento en dispositivos de red

para lograr diferentes niveles de rendimiento para flujos de tráfico (Figura 8.6). Como veremos, estos mecanismos están estrechamente vinculados a los SLAs y políticas, que se discuten a continuación.

Cola de Completamos esta sección con una discusión de Queue Server. Queue Server almacena los paquetes IP (esto puede aplicarse también a Marcos o a las células, pero para los propósitos de esta discusión nos limitamos a paquetes IP) dentro de un dispositivo de red mientras espera para su procesamiento. Puede haber varios lugares donde los paquetes son almacenadas (colas) dentro de un dispositivo de red, para cada tipo de procesamiento que el dispositivo está realizando en cada paquete (por ejemplo, manteniendo los paquetes recibidos de la red, procesamiento de calidad de servicio, con paquetes para la transmisión de en la red). Hay una serie de mecanismos colas disponibles en dispositivos de red. Cada mecanismo es desarrollado para lograr un objetivo particular en el procesamiento de paquetes. Por ejemplo, mecanismos de cola pueden tratar todos los paquetes de la misma manera, pueden seleccionar aleatoriamente paquetes para procesamiento o pueden favorecer paquetes particular. En este capítulo consideramos brevemente los siguientes mecanismos de colas: • Primero en el primero en salir (FIFO) • Cola basadas en clases (CBQ) • Weighted cola Feria (WFQ) • Al azar detectar temprano (rojo) • RED ponderada (WRED)

En primer lugar en primero hacia fuera cola (FIFO) es el mecanismo de cola más simple disponible. En FIFO colas los paquetes se almacenan en una cola única. Para una cola FIFO de salida, los paquetes son transmitidos en la red en el orden en que fueron recibidos (en la cola de entrada). En la clase cola (CBQ), se mantienen múltiples colas con prioridades diferentes. Niveles de prioridad son configurables en el dispositivo de red e indican los niveles de desempeño requeridos para cada tipo de tráfico. Paquetes de cada nivel de prioridad se colocan en sus respectivas colas. Las colas de mayor prioridad se procesan antes que las colas de menor prioridad, por lo que tráfico de mayor prioridad recibe más recursos de la red y por lo tanto mayor rendimiento. Como CBQ, cola equitativa ponderada (WFQ) asigna prioridades (pesos) a las colas. Normalmente con este mecanismo, los flujos de tráfico de alta prioridad se procesan primero, y los flujos de tráfico de menor prioridad compartan los recursos restantes. Generalmente, cuando una cola completa (por ejemplo, durante períodos de congestión), los paquetes se colocan ya sea desde el principio de la cola (la cabeza) o al final de la cola (cola). En cualquier caso, el lanzamiento de estos paquetes es probable ser desleal a uno o varios flujos de tráfico. Como resultado, al azar detectar temprano (rojo) fue desarrollado para aleatorizar el paquete dejando caer el proceso a través de una cola. Además, rojo dejará caer paquetes temprano (antes de la cola es realmente completa) para flujos de tráfico (es decir, flujos TCP) para ajustar al reducir su tasa de transmisión de la fuerza. Ponderado rojo (WRED) funciona de la misma manera como rojo pero soporta múltiples niveles de prioridades (una para cada cola) para dejar caer paquetes.

8.4.3 Acuerdos de nivel de servicio Acuerdos de nivel de servicioo SLA, son contratos formales (normalmente) entre un proveedor y el usuario que definen los términos de la responsabilidad del proveedor al usuario y el tipo y grado de rendición de cuentas si estas responsabilidades no son se reunieron. Mientras que SLAs tradicionalmente han sido contratos entre distintos prestadores de servicios (p. ej., ISP) y sus clientes, este concepto puede ser aplicado también para el entorno de la empresa. De hecho, la noción de cliente y proveedor es cada vez más común en redes de empresas, como evolucionan de tratar redes como mera infraestructura (enfoque de centro de costos) a tratarlos como centros de prestación de servicios a sus clientes (usuarios). Hay dos maneras comunes de SLA se aplican dentro de una red. En primer lugar, un SLA puede ser un acuerdo entre gestión y administración de la red y sus clientes (los usuarios de la red). En segundo lugar, un SLA puede utilizarse para definir los niveles de servicios requeridos de los proveedores de servicios de terceros (por ejemplo, proveedores de planta de cable, xSPs) para la red. SLA resultados elementos puede ser tan simples como una tarifa de datos (mínimo, máximo) y la tolerancia de la ráfaga (tamaño, duración) y puede dividirse en aguas arriba (en el

Origen destino (fregadero) Circulación de flujo de tráfico Figura 8.7 direcciones ascendente y descendentes

Dirección del lugar de destino a la fuente) y aguas abajo (en la dirección de la fuente al destino). Figura 8.7 muestra aguas arriba y aguas abajo de un flujo de tráfico, junto con las fuentes y sumideros. Mientras que estos términos se pueden aplicar para cualquier flujo, comúnmente se utilizan en redes de servicios. En estas redes, las fuentes de los flujos de tráfico la mayoría son servidores de Internet, y más destinos son PC de abonado a redes de acceso del proveedor de servicios. En este caso es aguas abajo de estos servidores (es decir, desde Internet) a la PC del abonado y aguas arriba es de la PC a Internet. Por ejemplo, páginas Web descargadas de Internet a la PC del suscriptor generar tráfico TCP aguas abajo desde un servidor Web para el suscriptor PC y reconocimientos TCP (TCP ACK) aguas arriba del suscriptor PC al servidor Web (Figura 8.8). SLAs pueden incluir retraso y métricas RMA para el aprovisionamiento más completa del servicio. En la figura 8.9 se muestra un ejemplo de una empresa SLA. SLA en la figura 8.9 especifica capacidad, retardo y niveles de RMA para varios tipos de usuarios, sus aplicaciones y dispositivos. Un nivel de servicio básico, o esfuerzo, se muestra, donde todas las características de rendimiento son mejores esfuerzos. Este nivel de servicio es el valor predeterminado y normalmente se prestaría a cualquier usuario de forma gratuita.

Figura 8.8 direcciones ascendente y descendentes para el tráfico de Web de Internet Descripción del servicio de red para mi empresa

Niveles de servicio:

Capacidad desempeño

Servicio básico

Como disponible (mejor esfuerzo) 1.5 Mb/s

Servicio plata

(bidireccional)

Rendimiento del retardo Como disponible (mejor esfuerzo)

Como disponible (mejor esfuerzo)

Como disponible (mejor esfuerzo)

Como disponible (mejor esfuerzo) Como disponible (mejor esfuerzo)

10 Mb/s

Max 100 Ms ida y vuelta

Servicio oro

(bidireccional) (Burst 100 Mb/s)

(entre puntos especificados)

100/10 Mb/s hacia

MAX 40 Ms ida y vuelta

Servicio platino

arriba o hacia abajo

(entre puntos especificados)

(explosión a 1 Gb/s)

Fiabilidad Rendimiento

99.999% uptime (servidor, usuario)

Figura 8.9 ejemplo de una empresa SLA

Los otros niveles de servicio (plata, oro y platino) especifican mayores niveles de capacidad, demoras y performance de RMA. Es probable que se cobraría usuarios que suscriben a estos niveles de rendimiento para el uso. Esto puede tomar la forma de una carga interna dentro de cada organización, una asignación de recursos o ambos. Por ejemplo, se puede asignar cada suscriptor válido para el servicio platinum (sólo un determinado tipo de usuario se le permitirá usar este servicio, basado en el trabajo y las necesidades) N horas al mes. Más de N horas al mes de uso resultaría en una carga para la organización del usuario. Figura 8.9 representa un ejemplo de un SLA bastante complejo y se utiliza para ilustrar cómo puede estructurarse un SLA. En la práctica, son generalmente más simples, con dos o tres niveles de servicio SLA. Sin embargo, dependiendo de las necesidades de una organización, un SLA puede ser más complejo que nuestro ejemplo. Un SLA es un contrato entre usuario y proveedor de servicios acerca de los tipos de servicios prestados. En este sentido un SLA forma un bucle de retroalimentación entre usuarios y proveedores. El proveedor de servicios tiene la responsabilidad de controlar y administrar los servicios asegurar que los usuarios obtienen lo que esperan (y posiblemente están pagando), y los usuarios están enterados de lo que está disponible para ellos. Figura 8.10 muestra que, cuando los SLAs se añaden a la arquitectura de rendimiento, proporcionan un medio para la comunicación entre usuarios, personal y administración sobre las necesidades de funcionamiento y servicios. A fin de SLAs ser eficaz como bucles de retroalimentación, que necesitan para funcionar conjuntamente con monitoreo de rendimiento y problemas de reporte/tickets, como parte de la performance o arquitecturas de gestión de red.

Consideraciones sobre la arquitectura

Programación de QoS, priorización, gestión del tráfico, Mecanismos de funcionamiento Figura 8.10 con SLAs añadidos

8.4.4 Políticas de Las políticas son sistemas formales o informales de declaraciones de alto nivel y las reglas sobre cómo deben asignarse entre los usuarios de red recursos (y, por lo tanto, rendimiento). Se utilizan para crear y administrar uno o más objetivos de rendimiento. Políticas de completan el marco de funcionamiento de una red por el alto nivel de acoplamiento (por ejemplo, gestión) vista de cómo debe realizar la red, con los mecanismos para implementar el rendimiento en los dispositivos de red (QoS) y de retroalimentación con los usuarios (SLA) (figura 8.11). Las políticas pueden describir qué red, informática, almacenamiento, u otros recursos están disponibles para los usuarios, cuando los recursos están disponibles, o que los usuarios están autorizados a acceder ciertos recursos. En este sentido, estas políticas son similares a las políticas de seguridad o distribución. Información a menudo es implementado, almacenado y manejado en bases de datos de la política en la red. Se pasa información entre bases de datos y dispositivos de red usando el servicio común de política abierta (policías) y Protocolo ligero de acceso a directorios (LDAP).

8.5 Architectural Considerations En el desarrollo de nuestra arquitectura de rendimiento que debemos evaluar mecanismos potenciales de rendimiento, determinar donde puede aplicar dentro de la red,

Programación de QoS, priorización, gestión del tráfico, Figura 8.11 mecanismos de rendimiento con las políticas de agregado

y examinar los sistemas de relaciones internas y externas para esta arquitectura de componentes.

8.5.1 Evaluación de los mecanismos de funcionamiento de En este punto debe tener requisitos, objetivos, tipo de medio ambiente y el modelo arquitectónico y están listos para evaluar mecanismos potenciales de rendimiento. Al evaluar los mecanismos de funcionamiento, es mejor inicio simple (por ejemplo, DiffServ QoS) y el trabajo hacia soluciones más complejas sólo cuando sea necesario. Donde se aplicará un mecanismo de funcionamiento en una red determinada depende sobre todo de donde se encuentran a lo largo de la red, basado en los resultados de los requerimientos y análisis de flujo requisitos de desempeño.Además de los requisitos y el análisis de flujo, también podemos usar cualquier objetivos arquitectónicos que se han desarrollado, así como de los modelos arquitectónicos presentados en el capítulo 5. Recordar que el modelo arquitectónico de acceso/distribución de la base separa una red basada en la función, donde la red de núcleo soporta el transporte a granel de los flujos de tráfico, distribución redes soporte de flujos hacia y desde servidores y flujos de tráfico agregados de la red de acceso y redes de acceso son donde más los flujos de tráfico origen y año. Esta separación funcional de una red puede aplicarse al evaluar los mecanismos de funcionamiento. Por ejemplo, mecanismos de funcionamiento que operan en los flujos de tráfico individual (como control de admisión y señalización de recursos, IntServ y QoS de capa 2) se deben considerar donde los flujos de tráfico son más propensos a ser individual Consideraciones sobre la arquitectura

(por ejemplo, antes de que se agregan), como en redes de acceso. Mecanismos de funcionamiento que operan en agregados de los flujos de tráfico, como DiffServ, CBQ, WFQ rojo/WRED y MPLS, se deben considerar donde los flujos de tráfico son más propensos a ser agregados, tales como en distribución y redes de base, o en interfaces externas redes.

Un ejemplo de donde se pueden aplicar generalmente mecanismos de rendimiento se presenta en la figura 8.12. Tenga en cuenta que estas aplicaciones se deben considerar solamente como guías generales. Dependiendo de la red, cualquier mecanismo de funcionamiento se puede aplicar en cualquier área de una red. Junto con determinar las regiones de la red donde cada mecanismo de funcionamiento se aplicará, también tenemos que considerar los dispositivos que implementará cada mecanismo. Los ejemplos incluyen dispositivos de borde de DiffServ, donde son clasificados y marcados con los servidores de puntos de código DSCP y puntos de decisión de políticas (PDP), donde las políticas se configuran y mantienen flujos de tráfico. Aplicación de políticas en la política

Figura 8.12 aplicaciones generales de los mecanismos de funcionamiento de

puntos de ejecución (PEP), dispositivos de red que están configurados para el rendimiento (por ejemplo, a través de QoS).

8.5.2 Internal Relationships Las interacciones dentro de la arquitectura de rendimiento incluyen compensaciones entre el extremo final y asignación de prioridades, planificación y acondicionamiento de los flujos de tráfico, control de la admisión, por el salto y si los flujos son tratados individualmente o agregados en grupos. Las interacciones dentro de la arquitectura de rendimiento incluyen compensaciones a través del siguiente conjunto de funciones de flujo de tráfico: priorización, programación, acondicionado, control de admisión y agregación. Cuando se eligen las políticas, los SLAs y servicios diferenciados, parte de esta arquitectura de componente describe la colocación de bases de datos para obtener información política y SLA, incluyendo puntos de decisión de políticas (PDP), puntos de aplicación de políticas (PEP) y borde de DiffServ dispositivos.

8.5.3 External Relationships Relaciones externas son compensaciones, dependencias y restricciones entre la arquitectura de rendimiento y cada una de las arquitecturas componente (direccionamiento / enrutamiento, administración de redes, seguridad y otras arquitecturas de componentes que puede desarrollar). Hay relaciones externas comunes entre el funcionamiento y cada una de las otras arquitecturas de componentes, algunos de los cuales se presentan en los párrafos siguientes. Interacciones entre rendimiento y abordar/enrutamiento. Rendimiento se puede acoplar estrechamente con el enrutamiento a través de mecanismos tales como servicios diferenciados e integrados, RSVP y MPLS. Sin embargo, cuando ruteo simplicidad del protocolo es una prioridad alta, rendimiento puede desacoplado de reenvío. Interacciones entre el funcionamiento y administración de redes. Rendimiento depende de la gestión de red para configurar, monitorear, administrar, verificar y facturar por niveles de rendimiento en toda la red. Gestión de red ayuda a pareja QoS, SLA y políticas estableciendo rutas comunes de comunicaciones y protocolos de información de rendimiento. Además, administración de red puede atar gestión del desempeño al sistema de soporte al cliente las operaciones (OSS).

SLAs deben acoplarse con administración de redes, monitoreo y reporte de tickets de problemas. Esto proporciona el circuito de retroalimentación necesaria entre rendimiento y administración de redes, usuarios y personal de administración. Conclusiones

Figura 8.13 rendimiento está limitado por seguridad

Interacciones entre rendimiento y seguridad. Como veremos en la arquitectura de componentes de seguridad, mecanismos de seguridad suelen ser intrusivos, interceptar, inspeccionar y controlar el tráfico y acceso a la red. Estas acciones requieren de recursos de la red y procesamiento, aumentando el retardo de red. Medida que se aumenta la seguridad, mediante la adición de más mecanismos (y mecanismos que son más intrusivos) a la red, se disminuye el rendimiento. Considerando que la capacidad se puede aumentar a veces para compensar una disminución del rendimiento debido a la seguridad, mayor retraso es difícil de mitigar. Cuando el rendimiento es de alta prioridad, especialmente cuando hay una necesidad de proporcionar performance end-to-end entre seleccionar usuarios, aplicaciones o dispositivos, mecanismos de funcionamiento puede impedir el uso intrusivo de mecanismos de seguridad en las zonas de la red. Cuando los mecanismos de seguridad interrumpirán o terminan y regeneran flujos de tráfico, que afecten seriamente la capacidad para proporcionar un rendimiento extremo a extremo a través de la interfaz de seguridad. Como resultado, seguridad limita el rendimiento para operar dentro de un perímetro de seguridad (Figura 8.13). Estos perímetros de seguridad, o zonas de seguridad o de las células, se puede configurar de diferentes maneras. Esto se discute más en el capítulo de arquitectura de seguridad (capítulo 9).

8.6 Conclusions En este capítulo hemos aprendido sobre el desarrollo de la arquitectura de rendimiento de una red. La arquitectura de rendimiento consiste en determinar que mecanismos (calidad de servicio, priorización, programación, acondicionamiento del tráfico, acuerdos de nivel de servicio y políticas) se aplican a un particular el desempeño de la red, donde cada mecanismo puede aplicar y las relaciones dentro de la arquitectura de desempeño y entre desempeño y otras arquitecturas de componentes. La arquitectura de rendimiento es la primera de las arquitecturas de componente que analizaremos. Medida que vamos pasando por cada componente, surgirá la arquitectura de referencia para la red (que consiste en todas las relaciones externas).

8.7 Exercises

Ejercicios 1 a 6, se refieren a los requisitos de rendimiento siguientes. Requisito 1. Dos grupos claramente diferentes de requisitos de rendimiento de red: una RMA alto, otro bajo RMA (para esa red) Requisito 2. Un requisito para facturar a los suscriptores para el servicio de red y proporciona información de facturación del suscriptor Requisito 3. La combinación de tráfico de voz y datos de un cliente en una red común 1. Para cada requisito de desempeño mencionado, explicar por qué son necesarios los mecanismos de funcionamiento para apoyar el requisito de. 2. DiffServ y IntServ son dos enfoques para proporcionar QoS en redes IP, diseñadas para apoyar el desempeño desde diferentes perspectivas. ¿De los requisitos enumerados, que recomendarías: DiffServ? ¿IntServ? ¿Ambos o ninguno? Dar razones para sus decisiones. 3. ¿ Que los requisitos indicar solo nivel rendimiento? Funcionamiento de multi-tier? 4. Figura 8.5 muestra el tráfico acondicionado funciones: clasificación, marcado, medición, dar forma y caer. Para el requisito 3 (combinando el tráfico de voz y datos), describen cómo el proceso de acondicionamiento del tráfico, con estas cinco funciones de DiffServ, se aplicaría a este requisito. Asignar un punto de código de DiffServ (DSCP) para cada tipo de tráfico. 5. Combina los requisitos 2 y 3, escriba un SLA para esta red. Utilizar los requisitos de rendimiento siguientes: a. Tráfico de voz debe tener una disponibilidad (RMA) de 99.999% (excluyendo tiempos de mantenimiento programado), medido por todas partes en la red. b. El tráfico de datos debe tener una disponibilidad (RMA) de 99.99% (excluyendo tiempos de mantenimiento programado), medidos entre los servidores y dispositivos de usuario. Incluyen la muestra de precios para el requisito de 2. 6. Una arquitectura de rendimiento consiste en mecanismos de QoS, SLA y política, aplicados en dispositivos de red y servidores, para apoyar el desempeño dentro de la red (Figura 8.14). Dado que habrá una política y servidor de base de datos de SLA y ejercicios de IP

routers y switches Fast Ethernet con DiffServ QoS, delinear cómo QoS, SLA y las políticas podrían implementarse para apoyar a los dos grupos de rendimiento en el requisito 1.

Figura 8.14 la red para el ejercicio 6

7. Lista cuatro tipos de problemas que aborda la arquitectura de rendimiento. Dar ejemplos de cada tipo de problema. 8. Para los mecanismos de colas se muestra a continuación, dar un ejemplo de cómo cada uno se utilizaría dentro de una red. ¿Qué problema es resolver cada mecanismo? a. primer en la primera salida (FIFO) b. Cola basadas en clases (CBQ) c. Weighted fair queuing (WFQ) d. Temprano al azar detectar (rojo) e. Weighted RED (WRED)

CAPÍTULO CONTENIDO 9.1 Objectives 9.1.1 Preparation 9.2 Background 9.3 Plan de desarrollo de una seguridad y privacidad

9.4 Administración de la privacidad y seguridad 9.4.1 Análisis de amenazas 9.4.2 Políticas y procedimientos 9.5 Mecanismos de privacidad y seguridad 9.5.1 Conciencia y seguridad física 9.5.2 Protocolo y seguridad de aplicaciones 9.5.3 Cifrado y descifrado 9.5.4 Seguridad de red perimetral 9.5.5 Seguridad de acceso remoto 9.6 Architectural Considerations 9.6.1 Evaluación de mecanismos de seguridad 9.6.2 Relaciones internas 9.6.3 Relaciones externas 9.7 Conclusions 9.8 Exercises

358

9 Arquitectura de la privacidad y seguridad

Seguridad y privacidad de usuario, aplicación, dispositivo y recursos de red y datos son cada vez más importantes áreas de diseño y arquitectura de red. La seguridad está integrada en todas las áreas de la red y afecta a todas las demás funciones de la red. Para el buen funcionamiento de la seguridad dentro de una red, es crucial que las relaciones entre los mecanismos de seguridad, así como la arquitectura de seguridad y otras arquitecturas de componente, se comprende bien.

Superposición de seguridad en una red desarrollada fue una aproximación aceptable en el pasado. Hoy, sin embargo, seguridad debe integrarse en la red desde el principio para la red satisfacer las necesidades de los usuarios y de seguridad proporcionar protección adecuada.

9.1 Objectives En este capítulo aprenderá sobre diversos mecanismos de seguridad (tales como seguridad física, protocolo y seguridad de aplicaciones, cifrado/descifrado y perímetro y seguridad de acceso remoto) determinar las relaciones entre estos mecanismos y entre la seguridad y los otros componentes de la arquitectura y cómo desarrollar la arquitectura de seguridad.

9.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo, debe estar familiarizado con los conceptos básicos y mecanismos de seguridad. Algunas recomendaciones de fuentes de información incluyen: • Hacking expuestos: secretos de seguridad y soluciones de red, tercera edición por Stuart

McClure, Joel Scambray y George Kurtz, McGraw-Hill Osborne Media, septiembre de 2001. 359 • Arquitectura de seguridad de la información: un enfoque integrado para la seguridad en la

organización, por Jan Killmeyer Tudor, Auerbach, septiembre de 2000. • Firewalls y seguridad en Internet: rechaza el Hacker Wily, segunda edición William R. Cheswick, Steven M. Bellovin y Aviel D. Rubin, AddisonWesley profesional, febrero de 2003. • Interior de seguridad de red perimetral: la guía definitiva para Firewalls, redes privadas virtuales (VPN), Routers y sistemas de detección de intrusiones, segunda edición, Stephen Northcutt, Karen Fredrick, Scott Winters, Lenny Zeltser, y Ronald W. Ritchey, jinetes de nueva editorial, junio de 2005. • Manual de seguridad para ordenador, por Seymour Bosworth y Michel Kabay, John Wiley &

Sons, abril de 2002.

9.2 Background

Seguridad de red se define aquí como la protección de redes y sus servicios de acceso no autorizado, modificación, destrucción o divulgación. Ofrece garantía de que la red realiza correctamente sus funciones críticas y de que no hay efectos secundarios dañinos. Privacidad de la red es un subconjunto de seguridad de red, protección de redes y sus servicios de acceso no autorizado o la divulgación. Esto incluye todos los usuario, aplicación, dispositivo y datos de la red. Cuando se utiliza el término seguridad de red en este libro, incluye todos los aspectos de la privacidad de la red también. Hay tres consideraciones de seguridad clásico: protección de la integridad, la confidencialidad y la disponibilidad de datos y recursos de red y sistema. Estas consideraciones se discuten a lo largo de este capítulo y son parte integrales de la arquitectura de seguridad. Eficacia de la seguridad y privacidad combinan una comprensión de la seguridad de lo que significa a cada uno de los componentes del sistema, usuarios, aplicaciones, dispositivos y redes — junto con la planificación y ejecución de las políticas de seguridad y mecanismos. Necesidades de seguridad en la red proteger recursos de la red de ser minusválido, robado, modificados o dañados. Esto incluye la protección de dispositivos, servidores, usuarios y datos del sistema, así como los usuarios y de la organización privacidad e imagen. Ataques contra el sistema entre aparentemente inofensivo sondeo no autorizados y uso de los recursos y mantener los usuarios autorizados tengan acceso a recursos (denegación de servicio), modificación, robo o destrucción de recursos.

Desarrollo de un Plan de privacidad y seguridad

Este capítulo cubre cómo seguridad y privacidad pueden determinados y llevados a la arquitectura de red y el diseño. Esta es un área de gran interés y la rápida expansión y cambio en la comunidad de redes, por lo que presentamos conceptos y mecanismos deben ser válidas a través de una amplia gama de requisitos de seguridad. Discutir elementos de la administración de seguridad y diversos mecanismos de seguridad y privacidad, considerar cómo desarrollar un plan de seguridad y examinar los requisitos de seguridad. También definir las políticas de seguridad, realizar análisis de riesgo para la arquitectura y el diseño y desarrollar un plan de seguridad y privacidad. Luego discutimos la arquitectura de seguridad y privacidad.

9.3 Plan de desarrollo de una seguridad y privacidad Como comentamos en el capítulo anterior, el desarrollo de la arquitectura de cada componente se basa en nuestra comprensión de por qué esa función se necesita para esa red particular. Si bien se puede argumentar que la seguridad siempre es necesario, todavía tenemos que garantizar que los mecanismos de seguridad que se incorporan a la arquitectura óptimos para lograr los objetivos de seguridad de esa red. Por lo tanto, hacia el desarrollo de una arquitectura de seguridad, debemos responder las siguientes preguntas:

1. ¿Qué estamos intentando resolver, agregar, o diferenciar mediante la adición de mecanismos de seguridad para esta red? 2. ¿Son mecanismos de seguridad suficientes para esta red? Si bien es probable que cierto grado de seguridad es necesaria para cualquier red, debemos tener información de los análisis de las amenazas que nos ayude a decidir cuánta seguridad se necesita. Como con la arquitectura de rendimiento, queremos evitar implementar mecanismos (seguridad) sólo porque son interesantes o nuevos. Cuando se indican los mecanismos de seguridad, es mejor empezar simple y trabajar hacia una arquitectura de seguridad más compleja cuando se justifica. Sencillez puede lograrse en la arquitectura de seguridad mediante la implementación de mecanismos de seguridad sólo en áreas seleccionadas de la red (por ejemplo, en el acceso o distribución [servidor] redes), o utilizando sólo uno o algunos mecanismos, o seleccionando sólo aquellos mecanismos son fáciles de implementar, operar y mantener. En el desarrollo de la arquitectura de seguridad, debe determinar qué problemas de tu cliente está intentando resolver. Esto puede ser claramente en la definición de problema, desarrollada como parte del análisis de amenaza, o tal vez necesite investigar más lejos para responder a esta pregunta. Algunas zonas comunes que son tratadas por la arquitectura de seguridad incluyen: • Qué recursos necesitan ser protegidos • Qué problemas (amenazas) estamos protegiendo contra • La probabilidad de cada problema (amenaza)

Esta información se convierte en parte de su seguridad y privacidad plan de la red. Este plan debe ser revisado y actualizado periódicamente para reflejar el estado actual de las amenazas de seguridad a la red. Algunas organizaciones de revisión sus planes de seguridad anual, otros con más frecuencia, dependiendo de sus requerimientos de seguridad. Tenga en cuenta que puede haber grupos dentro de una red que tienen necesidades de seguridad. Como resultado, la arquitectura de seguridad puede tener diferentes niveles de seguridad. Esto equivale a los perímetros de seguridad o zonas en el capítulo anterior. Cómo se establecen las zonas de seguridad se discute más adelante en este capítulo. Una vez que ha determinado que los problemas se resolverán por cada mecanismo de seguridad, luego debe determinar si estos mecanismos de seguridad son suficientes para esa red. ¿Se resuelven totalmente los problemas del cliente, o son sólo una solución parcial? Si son una solución parcial, ¿hay otros mecanismos que están disponibles, o estarán disponible dentro de su marco de tiempo del proyecto? Puede planificar implementar mecanismos de seguridad básicos en el proyecto y actualizar o agregar a esos mecanismos en varias etapas en el proyecto.

9.4 Administración de la privacidad y seguridad La preparación y administración continua de la seguridad y privacidad en la red son muy importantes para el éxito de la arquitectura de seguridad. Como los requisitos y análisis de flujos,

entender cuáles son sus amenazas y cómo va a protegerse de ellas es un primer paso importante en el desarrollo de seguridad para su red. En esta sección se discuten dos componentes importantes en la preparación para la seguridad: Análisis de políticas y procedimientos de la amenaza.

9.4.1 Análisis de amenazas Un análisis de las amenazas es un proceso utilizado para determinar qué componentes del sistema necesitan ser protegidos y los tipos de riesgos para la seguridad (amenazas) que deben protegerse (Figura 9.1). Esta información puede utilizarse para determinar las ubicaciones estratégicas en Administración de la privacidad y seguridad

Figura 9.1 activos potenciales y amenazas a analizar

la arquitectura de red y el diseño donde seguridad puede razonablemente y efectivamente implementar. Un análisis de las amenazas por lo general consiste en identificar los activos a proteger, así como identificar y evaluar posibles amenazas. Activos pueden incluir, pero no se limitan a: • Hardware del usuario (estaciones de trabajo/PC) • Servidores • Dispositivos especializados • Dispositivos de red (hubs, switches, routers, OAM & P) • Software (sistema operativo, utilidades, programas de cliente) • Servicios (aplicaciones, servicios IP) • Datos (local o remoto, almacenados, archivados, bases de datos, datos en tránsito)

Y las amenazas pueden incluir, pero no se limitan a: • Acceso no autorizado a los datos/servicios/software y hardware • Divulgación no autorizada de la información • Denegación de servicio • Robo de datos/servicios/software/hardware • Corrupción de datos/servicios/software/hardware

• Virus, gusanos, caballos de Troya • Daño físico

Un método para recopilar datos sobre la seguridad y privacidad para su entorno es una lista de las amenazas y los activos en una hoja de cálculo. Esta hoja de cálculo de análisis de amenaza puede distribuirse entonces a los usuarios, la administración y gestión, incluso como parte del análisis de requisitos de proceso, para recabar información sobre posibles problemas de seguridad. Efecto / probabilidad

Hardware del usuario

Servidores

Dispositivos de red

Software

Servicios

Datos

B/A

B/B

C/B

A/B

BYC

A/B

Divulgación no autorizada

BYC

B/B

C/C

A/B

BYC

A/B

Denegación de servicio

B/B

B/B

B/B

B/B

B/B

D/D

Robo

A/D

B/D

B/D

A/B

C/C

A/B

Corrupción

AIRE ACOND.

BYC

C/C

A/B

D/D

A/B

Virus

B/B

B/B

B/B

B/B

BYC

D/D

Daño físico

A/D

BYC

C/C

D/D

D/D

D/D

Acceso no autorizado

Efecto: probabilidad: A: B: destructivas deshabilitando A: ciertos B: probable C: D: disruptivo impacto C: D: improbable imposible Figura 9.2 ejemplo de una hoja de cálculo de análisis de amenazas para una organización específica

Un ejemplo de una hoja de cálculo se presenta en la figura 9.2. Los resultados mostrados en esta hoja de cálculo se determinaron durante el proceso de análisis de requisitos y son específicos de una determinada organización. Según la organización, los resultados de un análisis de las amenazas pueden ser distintos de los que se muestra en la figura 9.2. Por ejemplo, un análisis de la amenaza puede consistir en la información y activos que necesitan ser protegidos, en cuanto a la confidencialidad, integridad y disponibilidad. Este análisis puede combinarse con las listas de amenazas que existen actualmente hacia fuera, así como de posibles vulnerabilidades. Análisis de la amenaza son por su naturaleza subjetiva. Una de las maneras para reducir al mínimo el grado de subjetividad es involucrar a representantes de diversos grupos de la organización para participar en el proceso de análisis. Esto ayuda a conseguir muchas diferentes perspectivas en el análisis. También se recomienda que revises tu amenaza análisis periódicamente, tal como anualmente, para identificar cambios en su entorno. Una organización crece y cambia y como el

mundo exterior cambia, los grados y tipos de amenazas que esa organización también cambia. Un análisis de las amenazas periódicas garantiza que nuevas amenazas se incluyen y muestra donde nuevos mecanismos de seguridad Administración de la privacidad y seguridad

puede ser aplicado a la red. Junto con esto, también se recomienda una revisión periódica de las políticas de seguridad y procedimientos. Comentarios posteriores pueden resaltar áreas previamente pasados por alto en la red, el sistema y el medio ambiente.

9.4.2 Políticas y procedimientos Hay muchos compromisos en seguridad y privacidad (como con todos los demás componentes de la arquitectura), y puede ser una espada de doble filo. A veces se confunde seguridad con control sobre los usuarios y sus acciones. Esta confusión se produce cuando las reglas, regulaciones y guardianes de seguridad se colocan por encima de los objetivos y trabajan que la organización está tratando de lograr. El camino hacia la implementación de seguridad empieza con una toma de conciencia y comprensión de las debilidades de seguridad en la red y entonces conduce a la eliminación de estas debilidades. Generalmente pueden encontrar debilidades en las áreas de software de sistema y aplicación, las formas en que se apliquen mecanismos de seguridad, y en cómo los usuarios realizan su trabajo. Esta última zona es donde educar a los usuarios puede ser más beneficioso. Procedimientos y políticas de seguridad son declaraciones formales sobre las normas para el sistema, red y acceso a la información y el uso, con el fin de minimizar la exposición a las amenazas de seguridad. Definir y documentar cómo se puede utilizar el sistema con el mínimo riesgo de seguridad. Lo importante, pueden aclarar también a los usuarios Cuáles son las amenazas de seguridad, qué puede hacerse para reducir tales riesgos y las consecuencias de no ayudar a reducirlos. En un nivel alto, procedimientos y políticas de seguridad pueden presentar la filosofía de la seguridad global de una organización. Ejemplos de filosofías comunes de seguridad de alto nivel son específicos de negar y todo lo demás, aceptar o aceptar detalles y todo lo demás, como en la figura 9.3 negar. El término específico se refiere a normas bien definidas acerca de quién, qué y dónde se aplica la seguridad. Por ejemplo, puede ser una lista de rutas específicas que pueden ser aceptadas en esta red, o los usuarios que tienen permitidos el acceso a ciertos recursos. Seguridad que niega detalles y acepta todo lo demás refleja una filosofía de red abierta, que requiere una profunda comprensión de potenciales amenazas a la seguridad, como deben ser las características para ser negado. Puede ser difícil verificar la implementación de seguridad para esta filosofía, ya que es difícil de definir "todo lo demás". Por otra parte, la seguridad que acepta datos específicos y niega todo lo demás refleja una filosofía de red cerrada, que requieren un conocimiento profundo del usuario, aplicaciones, dispositivos y requerimientos de red, como éstos se convertirán en las características para ser aceptado. Es más fácil de validar esta aplicación de seguridad, ya que existe un conjunto finito (relativamente pequeño) de usos "aceptados". De las dos filosofías, aceptar detalles/negar todo lo demás es la filosofía más común.

Figura 9.3 ejemplo seguridad filosofías

Cuando usted desarrolla procedimientos y políticas de seguridad, recuerde que, a fin de que sean útiles, sean fácil de implementar para su entorno (teniendo en cuenta que les apoyaremos), ejecutables y han definido claramente las áreas de responsabilidad. Políticas y procedimientos deben incluir: • Declaraciones de privacidad (monitoreo, registro y acceso) • Declaraciones de responsabilidad (responsabilidades, de auditoría) • Declaraciones de autenticación (políticas de contraseñas, acceso remoto) • Reportes violaciones (información de contacto, procedimientos)

Ejemplos de procedimientos y políticas de seguridad son declaraciones de uso aceptable, procedimientos de manejo de incidente de seguridad, políticas de modificación de la configuración y control de red acceso listas (ACL). Cada uno de ellos tiene un lugar en el plan de seguridad y privacidad. Estas políticas y procedimientos deben describir no sólo como recursos de la red se pueden acceder, utilizar y modificados, sino por qué, para ayudar a los usuarios a entender las políticas se les pide aceptar y trabajar con. Procedimientos de manejo de incidente pueden ser particularmente útiles para concienciar a los usuarios de qué hacer cuando surge un problema de seguridad, que en el proceso de seguridad en lugar de a someterlos a él. La lista de áreas de políticas y procedimientos que se muestra a continuación puede utilizarse como punto de partida para aplicar a la arquitectura de seguridad: Acceso de usuario al sistema • Autorización de uso • Autenticación de identidad y uso de contraseñas

• Formación y aceptación de la responsabilidad para el cumplimiento de • Nota que el equipo empresarial no es propiedad privada • Expectativas de derecho a la intimidad

Administrador de competencias y requisitos para la certificación • Los superusuarios y administradores

Gestión y configuración del sistema

• Mantenimiento • Protección de virus/troyano • Parches de sistemas operativos y aplicaciones • Monitoreo de CERT de avisos para avisos de hacks • Supervisión que puede y no puede conectar dispositivos a la red • Manejo de pantallas de aviso durante inicio de sesión o Inicio • Establecer los datos que Haz copia de seguridad • Establecer qué datos se salva fuera del sitio • Desarrollo de planes de contingencia informáticos • Determinar qué hacer cuando el sistema es atacado

9.5 Mecanismos de privacidad y seguridad Hay varios mecanismos de seguridad disponibles hoy en día y muchos más en el horizonte. Sin embargo, no todos los mecanismos son apropiados para cada ambiente. Cada mecanismo de seguridad debe ser evaluado para la red se está aplicando, basado en el grado de protección que ofrece, su impacto en la capacidad de los usuarios para trabajar, la cantidad de experiencia necesaria para la instalación y configuración, el costo de la compra, implementación y operación y las cantidades de administración y mantenimiento. En esta sección abarcamos seguridad física y conciencia, protocolo y seguridad de aplicaciones, cifrado/descifrado, seguridad perimetral de red y seguridad de acceso remoto.

9.5.1 Conciencia y seguridad física Seguridad física es la protección de dispositivos de acceso físico, daños y robo. Dispositivos suelen red y sistema de hardware, como dispositivos de red (routers, switches, hubs, etc.), servidores y dispositivos especializados, pero también pueden ser software CD, cintas o dispositivos periféricos. Seguridad física es la forma más básica de seguridad y la que es más intuitivo para los usuarios. Sin embargo, a menudo se olvida en el desarrollo de un plan de seguridad. Seguridad física debería abordarse como parte de la arquitectura de red incluso cuando el campus o edificio tiene restricciones de acceso o guardias de seguridad. Maneras de implementar seguridad física incluyen los siguientes (véase figura 9.4): • acceso controlado habitaciones (por ejemplo, a través de las llaves de tarjeta) para dispositivos compartidos (servidores) y dispositivos especializados. • Fuentes de alimentación y acondicionamiento de potencia

• Almacenamiento fuera del sitio y el archivo • Sistemas de alarma (por ejemplo, fuego e ilegal alarmas de entrada)

Seguridad física también se aplica a otros tipos de amenazas físicas, tales como desastres naturales (por ejemplo, incendios, terremotos y tormentas). La seguridad de los desastres naturales incluye protección al fuego (usando sistemas de alarma y equipo de disminución de fuego), agua (con mecanismos de protección del agua-extracción/bombeos y otros) y degradación estructural (a través de tener dispositivos en bastidores al pisos, paredes, etcetera). Abordar la seguridad física sienta las bases para su plan de privacidad y seguridad de toda la red. Aplicación OS Red

Figura 9.4 áreas de seguridad física

Conciencia de seguridad consiste en conseguir usuarios educados involucrados con los cotidiana los aspectos de seguridad en su red y ayudándoles para entender los riesgos potenciales de violación de procedimientos y políticas de seguridad. Conciencia de seguridad puede promoverse a través de ofrecer sesiones sobre seguridad, donde los usuarios tienen la oportunidad de discutir los temas y expresar sus opiniones y problemas con mecanismos de seguridad, políticas y procedimientos y potencialmente ofrecen opciones para la seguridad y privacidad; por proporcionar a los usuarios los boletines o newsletters (o agregando información al boletín de la organización) sobre seguridad de la red y lo que los usuarios pueden hacer para ayudar; y por proporcionar a los usuarios información sobre los últimos ataques de seguridad.

9.5.2 Protocolo y seguridad de aplicaciones En esta sección consideramos algunos mecanismos de seguridad comunes del protocolo y aplicación: IPSec, SNMP y filtrado de paquetes. IPSec es un protocolo para proporcionar autenticación y cifrado/descifrado entre dispositivos en la capa de red. Mecanismos IPSec consisten en encabezado de autenticación (AH) y carga de seguridad encapsulado (ESP). Hay dos modos que IPSec opera en: transporte y túnel. En el modo de transporte la carga útil IP se encripta usando ESP, mientras que la cabecera IP se deja en claro, como se muestra en la figura 9.5. En el modo de túnel IPSec (Figura 9.6) puede utilizarse para encapsular paquetes entre dos gateways de la red privada virtual (VPN) (IPb yc de la IP en la figura). El proceso de túnel consiste en lo siguiente: • Se crean túneles IPSec entre VPN gateways IPb y IPc en Figura 9.6 • los paquetes IP se encriptan

con ESP

Figura 9.5 el modo de transporte de IPSec

IPd Dest: d

Fuente: una

Figura 9.6 el modo túnel de IPSec

• Estos paquetes son encapsulados dentro de otro paquete IP y dirigidos con los extremos del

túnel IPSec (IPb yc IP) • Al final del túnel (la puerta de enlace VPN que sirve IPd), el paquete original es encapsular y

descifrado y enviado a su destino IPd. Este es un ejemplo de túnelo información encapsulado en encabezados de protocolo con el fin de aislar y proteger esa información. Tenga en cuenta que esto es diferente de la encapsulación del protocolo tradicional, que se utiliza para apoyar diferentes funciones en cada capa de protocolo. Redes privadas virtuales aplicarán este concepto túnel para crear múltiples redes aisladas a través de una infraestructura común. Túneles y VPN es métodos comunes para la construcción de una red aislada a través de una infraestructura común como Internet. Seguridad para la versión 3 del Simple Network Management Protocol (SNMPv3) se describe en el modelo de seguridad basado en el usuario (USM), protección contra la modificación de la información, mascaradas, modificación de secuencia de mensaje e información a revelar (escuchas). Seguridad SNMP proporciona las siguientes capacidades de seguridad: • SNMP mensaje verificación (integridad de datos), verificación de la identidad del usuario (autenticación

de origen de datos) y confidencialidad de los datos (a través de authProtocol de , authKey, privProtocol y privKey ) • Detecta mensajes SNMP que han superado los umbrales de tiempo (repetición de mensaje

limitada de puntualidad) (vía snmpEngineID, snmpEngineBootsy snmpEngineTime )

Negar el origen/destino 0.0.0.0 Permite el puerto 23 Negar todos los demás puertos Figura 9.7 ejemplo de filtrado de paquetes

Seguridad SNMP también incluye mecanismos de cifrado y descifrado (privProtocol y mecanismos de autenticación (authProtocol)): • HMAC-MD5-96 (128-bit mensaje digest algoritmo (MD5) criptográficas hash-función, modo de

autenticación de mensaje de códigos (HMAC), truncado a 96 bits) • HMAC-SHA-96 (algoritmo de Hash seguro) • CBC-DES (Protocolo de cifrado bloque encadenamiento de modo simétrico de cifrado/descifrado

Seguridad SNMP también permite modificar MIB vistas y modos de acceso. Por ejemplo, es posible tener diferentes vistas MIB definibles para diferentes grupos, y modos de acceso (RO, RW) también son definibles para diferentes grupos y están ligados a vista MIB. Filtrado de paquetes es un mecanismo en los dispositivos de red explícitamente negar o pasar los paquetes en puntos estratégicos dentro de la red. A menudo se utiliza para denegar paquetes hacia o desde particular direcciones IP o puertos (servicios), como en la figura 9.7.

9.5.3 Cifrado y descifrado Mientras que otros mecanismos de seguridad proporcionan protección contra accesos no autorizados y destrucción de recursos e información, encriptación/descifrado protege la información de ser usable por el atacante. Cifrado y descifrado es un

Cifrado y descifrado del cifrado y descifrado Dispositivo de Figura 9.8 cifrado y descifrado de tráfico de red

mecanismo donde se aplican los algoritmos de cifrado con una clave secreta para cifrar datos para que sean ilegibles si se interceptan. Los datos son entonces descifrarse en o cerca de su destino. Esto se muestra en la figura 9.8. Como tal, de cifrado/descifrado mejora otras formas de seguridad protección de la información en caso de fallan de otros mecanismos evitar que usuarios no autorizados que la información. Hay dos tipos comunes de cifrado/descifrado: clave pública y clave privada. Las implementaciones de software de cifrado y descifrado de clave pública están comúnmente disponibles. Los ejemplos incluyen datos cifrado estándar (DES) privado clave de cifrado triple DES cifrado de clave privada y cifrado de clave pública Rivest, Shamir y Adleman (RSA). Infraestructura de clave pública (PKI) es un ejemplo de una infraestructura de seguridad que utiliza claves públicas y privadas. Infraestructura de clave pública es una infraestructura de seguridad que combina mecanismos de seguridad, políticas y directivas en un sistema que está dirigido para el uso a través de redes públicas sin garantía (por ejemplo, Internet), donde la información es cifrado mediante el uso de un público y un par de claves criptográfico privado que es obtenido y compartido a través de una autoridad de confianza. PKI está orientada hacia las transacciones legales, comerciales, oficiales y confidenciales e incluye un sistema de gestión de certificados y claves criptográficas. Los componentes de este sistema son: • Gestión de la generación y distribución de claves públicas/privadas • Publicar las claves públicas con UID como certificados en directorios abiertos • Asegurar que las claves públicas específicas verdaderamente están vinculadas a las claves

privadas específicas • Autenticación del titular de un par de claves pública y privada

PKI utiliza uno o más de confianza sistemas conocidos como autoridades de certificación (CA), que sirven como terceras partes de confianza para PKI. La infraestructura PKI es jerárquica, con emisión de autoridades, autoridades de registro, autenticación de autoridades y las autoridades locales de registro. Otro ejemplo es la biblioteca de sockets seguros (SSL). Biblioteca de sockets de seguro es un mecanismo de seguridad que utiliza autenticación de RSA para reconocer la identidad digital de una parte y utiliza el RC4 para cifrar y descifrar la transacción o comunicación acompañamiento. SSL ha crecido hasta convertirse en uno de los principales protocolos de seguridad en Internet. Una relación inversa con el cifrado y descifrado es una reducción en el rendimiento de la red. Dependiendo del tipo de cifrado/descifrado y donde se implementa en la red, rendimiento de la red (en términos de capacidad y retraso) puede ser degradado de 15% a 85% o más. Cifrado/descifrado generalmente también requiere administración y mantenimiento, y algunos equipos de cifrado/descifrado pueden ser caro. Mientras que este mecanismo es compatible con otros mecanismos de seguridad, compensaciones como estos se deben considerar al evaluar el cifrado y descifrado.

9.5.4 Seguridad de red perimetral

Para seguridad de red perimetral, o proteger las interfaces externas entre su red y redes externas, consideramos el uso de firewalls y mecanismos de traducción de dirección. Traducción de direcciones de red, o NAT, es la asignación de direcciones IP de un reino a otro. Esto suele ser entre el espacio de direcciones IP pública y privada. Espacio de direcciones IP privado es el conjunto de espacios de direcciones privado definido por el IETF (RFC 1918): • Prefijo de número de clase A 10.x.x.x/8 10 • Prefijo de número de clase B 172.16 172.16/12 • Prefijo de número de 192.168 192.168/16 clase C

NAT se utiliza para crear enlaces entre direcciones, como la dirección individual vinculante (NAT estática); vinculante de la dirección de uno a muchos (NAT dinámico); y los enlaces de la dirección y el puerto (traducción de puerto de direcciones de red o NAPT). Mientras que NAT se desarrolló para abordar los problemas del agotamiento del espacio de dirección, rápidamente fue adoptado como un mecanismo para mejorar la seguridad en las interfaces externas. Rutas en espacios de direcciones IP privadas no se propagan en Internet; por lo tanto, el uso de direcciones IP privadas esconde la estructura interna del direccionamiento de una red desde el exterior. La arquitectura de seguridad debe considerar una combinación de estática y dinámica NAT y NAPT, basados en los dispositivos que están siendo protegidos. Por ejemplo, NAT estática es de uso frecuente para los enlaces a múltiples usuarios dispositivos como servidores o dispositivos informáticos de gama alta, mientras que NAT dinámico se utiliza con dispositivos informáticos genéricos. Los cortafuegos son combinaciones de uno o más mecanismos de seguridad, implementados en dispositivos de red (routers) colocados en lugares estratégicos dentro de una red. Cortafuegos pueden estar filtrando gateways, servidores proxy de aplicación con pasarelas de filtrado, o dispositivos que ejecutan software especializado "firewall".

9.5.5 Seguridad de acceso remoto Acceso remoto consiste en tradicional dial-en las sesiones de punto a punto y las conexiones de red privada virtual, como se muestra en la figura 9.9. Seguridad para acceso remoto incluye lo que comúnmente se conoce como AAAA: autenticación de usuarios; autorización de recursos para los usuarios autenticados; contabilidad de recursos y prestación de servicios; y la asignación de información de configuración (por ejemplo, direcciones o por defecto de la ruta). AAAA es apoyado generalmente por un dispositivo de red como un servidor de acceso de red (NAS) o un sistema de gestión de abonado (SMS). Seguridad de acceso remoto es común en las redes de servicios (véase también el modelo de arquitectura de proveedor de servicios), pero está evolucionando en redes empresariales como las empresas reconocen la necesidad de apoyar un modelo de acceso remoto a sus redes. Consideraciones al proporcionar acceso remoto son los siguientes (véase figura 9.10): • Métodos de AAAA

• Tipos de servidor y ubicación (por ejemplo, DMZ) • Interacciones con DNS, dirección de piscinas y otros servicios

Mecanismos de acceso remoto Figura 9.9

Figura 9.10 consideraciones de acceso remoto

Figura 9.11 se muestra la interacción del protocolo el Protocolo punto a punto (PPP), PPP sobre Ethernet (PPPoE) y servicio de acceso remoto dial-en usuario (RADIUS) en una red de acceso remoto. Esta figura muestra el proceso de establecer una sesión PPPoE, en el que se inicia una sesión PPP. PPPoE proporciona una cuña entre Ethernet y PPP, apoyo a la naturaleza de punto a punto máximo de sesiones PPP sobre una red Ethernet broadcast. Por lo tanto, una sesión PPPoE comienza con un paquete de difusión, la iniciación de descubrimiento activo de PPPoE (PADI). Este paquete comienza un apretón de manos entre el ordenador y NAS, de PADI, PPPoE active el usuario oferta de descubrimiento (PADO), solicitud de descubrimiento activo de PPPoE (PADRI) y paquetes de sesión (PADS) de descubrimiento activo de PPPoE. La sesión PPP puede comenzar en la realización de esta parte del proceso. Una sesión PPP tiene tres etapas: vincular el establecimiento, la autenticación y la capa de red. Cada etapa se construye sobre el anterior para establecer la sesión PPP. Una vez que se han establecido sesiones PPPoE y PPP, el usuario puede comenzar a usar la red. Autenticación en una red de acceso remoto se realiza típicamente mediante una combinación de protocolos PPP, PPPoE, PAP, CHAP y radio. Otros mecanismos de autenticación en la red de acceso

remoto incluyen tokens, tarjetas inteligentes, certificados digitales y devolución de llamada. VPNs y túneles pueden considerarse también como parte de la red de acceso remoto. VPNs son un ejemplo de lo que puede considerarse una subarquitectura. VPNs, por sí mismos, pueden requerir su propio conjunto de consideraciones sobre la arquitectura. Esto es particularmente cierto cuando hacen una extranet es una intranet extendida para incluir acceso a o desde las organizaciones externas (clientes, proveedores) pero no al general público. Estas consideraciones incluyen tipos de equipos, construcción de túneles

Figura 9.11 proceso de establecimiento de sesión PPP/PPPoE

protocolos y seguridad, lugares de VPN, las políticas de provisioning de VPN y soporte y el uso de protocolos de enrutamiento como el protocolo de gateway fronterizo (BGP) o multi-protocol label conmutación (MPLS). Por último, seguridad de acceso remoto debe considerar también las comunicaciones inalámbricas y los dispositivos informáticos portátiles usando estándares como 802.11 y Alianza de redes de Homephoneline (homePNA). Inalámbricos pueden dirigirse a un número de ambientes, tales como movilidad, portabilidad y la computación nómada.

Consideraciones sobre la arquitectura

9.6 Architectural Considerations En el desarrollo de nuestra arquitectura de seguridad que necesitamos evaluar potenciales mecanismos de seguridad, donde puede aplicar dentro de la red, así como los sistemas de relaciones internas y externas para esta arquitectura de componentes.

9.6.1 Evaluación de mecanismos de seguridad En este punto tenemos requisitos, objetivos, tipo de medio ambiente y el modelo arquitectónico y están listos para evaluar potenciales mecanismos de seguridad. Como con cada arquitectura de componentes, al evaluar los mecanismos para una arquitectura, es mejor empezar simple y trabajo hacia soluciones más complejas sólo cuando sea necesario. Donde se aplicará un mecanismo de seguridad en una red determinada depende sobre todo de donde los requisitos de seguridad se encuentran en toda la red, y cuáles son los requisitos de seguridad, basado en los resultados del plan de análisis y de la seguridad y privacidad de requisitos . Los modelos arquitectónicos presentados en el capítulo 5 pueden ayudar a determinar donde se pueden aplicar mecanismos de seguridad en la red. Por ejemplo, el modelo arquitectónico de acceso/distribución de la base, que separa una red basada en la función, se puede utilizar como

punto de partida para la aplicación de mecanismos de seguridad. Usando este modelo, seguridad se puede aumentar en cada nivel, de la red de acceso a redes de distribución de redes de núcleo, por cualquiera de los dos mecanismos de seguridad agregando o mejorando la cantidad de seguridad proporcionada por cada mecanismo. Esto se muestra en la figura 9.12. En esta figura, seguridad aumenta de acceso a la distribución a las áreas, mediante la adición de mecanismos de seguridad en cada área o por aumento del nivel de seguridad (es decir, aumento) en cada nivel. Para este modelo arquitectónico, más

Figura 9.12 el modelo arquitectónico de la base de acceso de distribución como punto de partida para la seguridad

flujos de tráfico son de origen/año en redes de acceso y viajan a través de redes de núcleo y distribución. Añadiendo mecanismos o mejorar mecanismos de cada nivel, un flujo de tráfico encuentra mayores niveles de seguridad mientras se mueve de acceso a la distribución a redes de núcleo. En Figura 9.12 tráfico flujos de usuario A usuario c viajar a través de redes de acceso y distribución y se encuentran dos niveles de seguridad: firewalls de nivel 1 y nivel 2, donde el nivel 2 es más seguridad que el nivel 1. Un firewall de nivel 2 puede tener una más completa acceso control lista (ACL), normas más estrictas para el filtrado de tráfico, o una mayor capacidad de detección y registro. Tráfico fluye desde C de usuario a usuario un viaje a través de redes de núcleo, distribución y acceso. Como tráfico se mueve desde C de usuario a la red de núcleo, encontraría varios mecanismos de seguridad (detección de intrusos, cortafuegos, cifrado/descifrado y filtros de paquetes), con la seguridad creciente del acceso a distribución a la base. Además, como el tráfico se mueve de la red de núcleo a usuario A, se encuentra con tres niveles de cortafuegos. De manera similar, los modelos arquitectónicos de la intranet/extranet y de proveedor del servicio también pueden utilizarse para desarrollar un marco para la seguridad en una red. Como se mencionó en el último capítulo, perímetros de seguridad (es decir, las zonas de seguridad o las células) se pueden desarrollar dentro de una red, para dar cabida a múltiples niveles de requisitos de seguridad. Dos métodos comunes de zonas de seguridad en vías de desarrollo son para aumentar la seguridad al mover más profundo en la red (en la figura 9.12 se muestra un ejemplo de esto), o para desarrollar las zonas donde se necesitan en la red, independientemente de la topología. Cuando se desarrollan las zonas de seguridad para aumentar la seguridad al mover más profundo en una red, se incrustan dentro de otras, como se muestra en la figura 9.13. En un sentido los niveles de seguridad parecen las capas de una cebolla, con las capas más internas con el más alto nivel de seguridad.

Zonas de seguridad se basan en los distintos requisitos de seguridad durante el proceso de análisis de requisitos y deben describirse en el plan de privacidad y seguridad. Puede haber requisitos diferentes niveles de seguridad, juntada a grupos de usuarios, sus aplicaciones, dispositivos o dispositivos que se comparten entre los usuarios. Zonas de seguridad desarrolladas para satisfacer estas exigencias pueden ser dispersadas por toda la red y pueden incluso superponerse uno con el otro. Un ejemplo de esto se presenta en la figura 9.14. En esta figura se muestran cinco zonas de seguridad, basado en requisitos de seguridad diferentes. La primera zona (nivel de seguridad 1) cubre toda la red y está diseñada para proporcionar un nivel general de la seguridad para todos los usuarios, aplicaciones y dispositivos. Esto puede incluir el registro y detección de intrusiones. La segunda zona (nivel de seguridad 2) Consideraciones sobre la arquitectura

Las zonas de seguridad Figura 9.13 incrustado dentro de unos a otros

Figura 9.14 desarrollo de zonas de seguridad a través de una red

proporciona un mayor nivel de seguridad entre esta red y las redes externas. Esto puede incluir NAT y firewalls. La tercera zona (nivel de seguridad 3) proporciona otro nivel de seguridad para todo un grupo de usuarios, aplicaciones y dispositivos (Grupo D), cuyos requisitos de seguridad son diferentes del resto de la red. Por ejemplo, este grupo puede manejar información financiera o propietario de la empresa. La cuarta zona (nivel de seguridad 4) proporciona seguridad para un subconjunto de los usuarios, aplicaciones o dispositivos de múltiples grupos (grupos A y B). Se trata de seleccionarlos usuarios, aplicaciones, o dispositivos cuya seguridad necesita son diferentes de otros en sus

grupos. Por ejemplo, puede trabajar en proyectos clasificados por la empresa, produciendo datos que necesitan ser protegidos del resto de los grupos. Las terceros y cuarta zonas pueden aplicar mecanismos para proteger sus datos, tales como cifrado y descifrado y pueden tener protección de acceso a través de firewalls y filtrado de paquetes. La quinta zona (seguridad nivel 5) es la seguridad para dispositivos utilizados por varios usuarios, como servidores. Esta zona puede emplear monitoreo, registro y autenticación para verificar el acceso de los usuarios. 9.12 y 9.13 9.14 las figuras muestran cómo se pueden aplicar mecanismos de seguridad en una red para lograr múltiples niveles de seguridad o zonas.

9.6.2 Internal Relationships Las interacciones dentro de la arquitectura de seguridad incluyen compensaciones, dependencias y restricciones entre cada uno de los mecanismos de seguridad para su red. Por ejemplo, algunos mecanismos de seguridad requieren la capacidad para ver, añadir o modificar varios campos de información dentro del paquete. Información de direcciones IP NAT cambios entre los dominios público y privado la dirección. Mecanismos de cifrado y descifrado pueden cifrar campos de información, imposibilitando a otros mecanismos.

9.6.3 External Relationships Relaciones externas son compensaciones, dependencias y restricciones entre la arquitectura de seguridad y cada una de las arquitecturas componente (direccionamiento/enrutamiento, gestión de red, rendimiento y otras arquitecturas de componentes que puede desarrollar). Hay algunos más comunes, algunos de los cuales se presentan a continuación. Las interacciones entre la seguridad y abordar/enrutamiento. NAT es un mecanismo de direccionamiento que se utiliza a menudo para mejorar la seguridad. Por lo tanto, cuando se aplica para la seguridad, también afecta a direccionamiento para la red. Además, direccionamiento dinámico puede interferir con las medidas de protección específicas de dirección y con el registro. Conclusiones

Figura 9.15 los mecanismos de seguridad pueden restringir o impedir el rendimiento dentro de cada zona

Es más difícil determinar lo que está sucediendo cuando las direcciones IP se cambian con frecuencia. Las interacciones entre la seguridad y administración de redes. Seguridad depende de gestión de red para configurar, monitorear, administrar y verificar los niveles de seguridad en toda la red. Además, hay una necesidad de mantenimiento acceso incluso durante ataques donde el acceso en banda a los dispositivos de red no está disponible. Por ejemplo, cuando los dispositivos no están en el mismo lugar, usando dial-up para acceso fuera de banda es una potencial posición a tomar.

Interacciones entre seguridad y rendimiento. Seguridad y el rendimiento a menudo están en desacuerdo, como mecanismos de seguridad pueden afectar el rendimiento de la red. Las zonas de seguridad descritas anteriormente en este capítulo pueden limitar el rendimiento dentro de las áreas, según las zonas. Cuando la seguridad es una prioridad, los mecanismos de seguridad que afectan a los flujos de tráfico podrán restringir los mecanismos de funcionamiento para operar dentro de zonas de seguridad o rendimiento se reducen al mínimo para esa zona (Figura 9.15). Cuando el rendimiento es de alta prioridad, especialmente cuando hay una necesidad de proporcionar performance end-to-end entre seleccionar usuarios, aplicaciones o dispositivos, mecanismos de funcionamiento puede impedir el uso intrusivo de mecanismos de seguridad en las zonas de la red.

9.7 Conclusions En este capítulo discutimos varios posibles mecanismos de seguridad para su arquitectura de seguridad, incluyendo la seguridad física, protocolo y seguridad de aplicaciones, cifrado/descifrado y perímetro y seguridad de acceso remoto. Base en la información de los análisis de requisitos, desarrollamos entrada para un plan de seguridad y privacidad. También hablamos de elementos de las relaciones internas y externas para la arquitectura de seguridad.

9.8 Exercises Ejercicios 1 al 3, consulte Figura 9.16.

Figura 9.16 red para los ejercicios 1 a 3

1. Desarrollar un análisis de la amenaza de la muestra para la red en la figura 9.16, o para una red que está familiarizado con. Mostrar activos y amenazas potenciales como en la figura 9.2.

2. Mecanismos de aplicar la seguridad de este capítulo para apoyar los siguientes requisitos. Mostrar donde cada mecanismo podría ser aplicado. a. Una intranet entre cada uno de los routers conectados a la red WAN. b. Seguridad de acceso remoto para cada uno de los 15 routers telefónico conectado a la LAN en Washington, DC. c. Todos los flujos de tráfico entre Los Ángeles y Minneapolis deben encriptarse. Ejercicios

3. Resumen el desarrollo de DMZs que se aplicarían en cada sitio donde se hacen las conexiones a otros sistemas autónomos (AS). ¿Cuáles serían los tipos de dispositivos utilizados en estos sitios? 4. Figura 9.17 muestra cinco zonas de seguridad requeridas por el cliente. Estas zonas son prioridad, seguridad zona 5 proporciona seguridad básica para toda la red, y las zonas 2, 3, 4 y 1 con crecientes grados de seguridad, de zona 1 con el más alto nivel de seguridad. Para esta red: a. ¿Qué mecanismos de seguridad se pueden aplicar dentro de cada zona de seguridad y en las interfases entre las zonas de seguridad, lograr grados crecientes de seguridad? b. ¿ Que modelos arquitectónicos son más aplicables a esta red? Mostrar cómo se puede aplicar a cada modelo.

Figura 9.17 red para ejercicio 4

CAPÍTULO CONTENIDO 10.1 Objectives 10.1.1 Preparation 10.2 Conceptos de diseño 10.2.1 Analogía con un diseño de edificio

10.2.2 Diseño de productos 10.2.3 Entrada para el diseño 10.3 Proceso de diseño 10.4 Proveedores, equipos y las evaluaciones del proveedor de servicios de 10.4.1 Siembra el proceso de evaluación 10.4.2 Debates de candidatos 10.4.3 Recopilación de datos 10.4.4 Criterios de refinamiento y desarrollo de calificaciones 10.4.5 Clasificación y priorización 10.4.6 Modificar el conjunto de candidatos 10.4.7 Determinar el orden de las evaluaciones 10.5 Diseño de la red 10.5.1 Diagramas de lógicas 10.5.2 Planos de red

10.5.3

Componente planes

10.6 Trazabilidad de diseño 10.7 Métricas de diseño 10.8 Conclusions 10.9 Exercises

384

10 Diseño de redes Diseño de la red añade detalle producto, proveedor, ubicación y configuración a la arquitectura. Nuestro trabajo de análisis y arquitectura realizada hasta la fecha ayuda a hacer el proceso de diseño sencillo, reproducible y bien documentado. De hecho, cuando los procesos de análisis y arquitectura se hacen bien, el proceso de diseño se vuelve relativamente fácil.

Algunos lectores pueden sentir que la razón que es simple el proceso de diseño es que ya hemos hecho más de lo que tradicionalmente se denomina "diseño" durante el análisis y la arquitectura. Esto es algo cierto; sin embargo, las decisiones de diseño tomadas sin el beneficio de los procesos de análisis y arquitectura son decisiones ad hoc, sin una comprensión suficiente de lo que estamos tratando de lograr (declaraciones del problema y objetivos), lo que necesitamos () requisitos), y como componentes de red trabajarán juntos (arquitectura). Resultados de la toma de decisión ad hoc en un montón de trabajo en el extremo posterior del proyecto, en términos de resolución de conflictos y tratar de entender, justificaran y explican el diseño. Al mover gran parte de la obra hacia adelante en el ciclo de vida del proyecto para el análisis y la arquitectura, estamos mejor preparados para tomar decisiones de diseño, adquisición de equipos y servicios y proporcionar el material de fondo para apoyar nuestras decisiones y nos podemos acoplar diseño decisiones de la arquitectura, los requerimientos y declaraciones de problema. Mi experiencia es que siempre se trata de una posición mucho mejor que en y bien vale la pena la inversión en tiempo y recursos. Desafortunadamente, hay una tendencia a saltar a una solución técnica sin la disciplina de análisis y arquitectura de los ingenieros. He visto esto suceder muchas veces, siempre con resultados menos positivos. Por ejemplo, me pidieron para participar en un proyecto de red que implica el desarrollo de una WAN nacional para reemplazar a uno que está fuera de fecha. Resultó que un reemplazo WAN ya había sido desarrollada, hecho rápidamente con un montón de dinero gastado, pero su diseño era ad hoc, sin requisitos ni previsión arquitectónico. Aunque había sido llevado a cabo y en lugar de más de un año, no había sido utilizado nunca y nunca se utilizaría. En los procesos de este libro hemos sido capaces de desarrollar un reemplazo WAN que fue gran éxito, superando las expectativas de rendimiento y escalabilidad del cliente. 385

10.1 Objectives En este capítulo aprenderás el proceso de diseño de la red. Este proceso se centra en dos áreas principales de trabajo para su diseño: evaluación de proveedores y prestadores de servicios, junto con sus productos y servicios; y el diseño de diagramación, es decir, desarrollo de planos detallados que proporcionan la disposición física para toda su información desarrollado hasta ahora. Aprenderás que un resultado fundamental de este trabajo es un conjunto de decisiones de diseño que son trazables a sus decisiones de arquitectura, requisitos y declaraciones de

problema. También aprenderá cómo trazar diseño decisiones decisiones arquitectónicas y cómo aplicar las métricas a las decisiones de diseño.

10.1.1 Preparation Para ser capaces de comprender y aplicar los conceptos en este capítulo a sus proyectos, usted debe estar familiarizado con los procesos de análisis y arquitectura discutidos a lo largo de este libro; actual y emergente de la red y las tecnologías de sistemas; topologías de red y su jerarquía asociada y las características de la diversidad; y proveedor de equipos y servicios (aunque vamos a través de mucho de esto en este capítulo).

10.2 Conceptos de diseño Diseño de red es el objetivo final de nuestro trabajo, la culminación de procesos de análisis y arquitectura de la red. Mientras que análisis de red proporciona conocimiento y arquitectura de red proporciona descripciones (tecnología y topología) conceptuales de la red, diseño de redes se basa en éstos para añadir detalle físico y proveedor, producto y selecciones de servicio a la red. La parte superior de la figura 10.1 muestra una arquitectura WAN de ejemplo que describe la topología general (una topología de anillo múltiple); lugares estratégicos en la red (instalaciones de Exchange independiente del portador (CIEFs) y puntos de la demarcación para cada centro y LAN Center); y la ubicación de los principales tipos de equipos (interruptores [S], routers [R] y dispositivos de vigilancia [M]. Junto con tal esquema habría descripciones de CIEFs y tipos de equipos cuando sea necesario. Además, opciones de tecnología podrían se muestra en este diagrama e incluidas en la descripción correspondiente. Esta arquitectura transmite los conceptos generales de la WAN, incluyendo la estructura general de la red (un conjunto de instalaciones del portador interconectado con los servicios de portador de anillos múltiples, con cada CIEF actúa como un hub para punto a punto

Figura 10.1 red diseño agrega detalle a la arquitectura

conexiones a un número de centros) y lugares generales para conmutadores, enrutadores y monitores. La parte inferior de la figura 10.1 es un ejemplo de cómo el diseño comienza a añadir detalles a la arquitectura. Esta figura muestra cómo interconectar centros y CIEFs. Utilizando términos genéricos como clase transportista switches y routers, el diagrama indica lo que estos dispositivos podrían ser, basado en proveedores y selecciones del producto durante el proceso de diseño. Algunos detalles también pueden ser mostrados en términos de la configuración de los dispositivos y cómo están conectados entre sí. Sin embargo, este diagrama no muestra todo el detalle posible en los productos o las ubicaciones físicas de los equipos. Es útil tener en cuenta que puede haber diferentes productos de diseño, ofreciendo distintos niveles de detalle dependiendo de quién es el destinatario del producto. Lo que se muestra en la figura 10.1 se puede considerar un producto de primer orden del diseño. No se pretende utilizar para instalar o configurar dispositivos, sino como un producto para la gestión, proporcionando así mayor fidelidad a la arquitectura pero no tanto como para ser

confuso. Lo que se muestra en la figura 10.1 ayuda a describir lo que se está evaluando y cómo muchos de los dispositivos serán necesario para un lugar en particular y es útil para la adquisición y planificación de conectividad general. Figura 10.2 muestra un producto de segundo orden para un centro desde el diseño mismo. Tenga en cuenta la mayor cantidad de detalles, incluyendo tipos de productos, niveles de revisión de hardware y software, configuraciones de dispositivo y un diseño más explícito de la conectividad entre dispositivos, así como con los proveedores de servicios. Productos de diseño de segundo orden proporcionan suficiente detalle para entender completamente la red, donde los dispositivos son en lo referente a uno otro, su ubicación general, y servicios como QoS y VoIP deben estar habilitados. Lo que falta de un producto de segundo orden como en la figura 10.2 es la ubicación real de cada pieza de hardware en el diseño de la red. Mientras que un producto de segundo orden puede proveer ubicaciones generales (edificios, pisos, habitaciones), un producto de la tercera orden añade detalle de ubicación. Por ejemplo, el diseño puede mostrar rack diseños y ubicación de cada dispositivo en un rack (o equivalente de hardware). Una parte importante de un producto de tercer orden está mostrando la conexión explícita entre dispositivos,

Figura 10.2 un producto de diseño de segundo orden

incluyendo las descripciones y diagramas de cables. Con un producto de tercer orden debe tener toda la información que necesita desde el diseño para instalar, configurar y operar la red. Es importante tener en cuenta que productos de tercer orden son los objetivos de máximos para el diseño. Usted puede terminar desarrollando productos de primer y segundo orden como subproductos mientras se trabaja en productos de tercer orden. Por lo tanto, no puede ser más trabajo de desarrollo de productos diseño de primer, segundo y tercer orden, y mediante la organización de sus productos de diseño en estas tres categorías puede apoyar a varios destinatarios del diseño. Por ejemplo, en el proceso de desarrollo de productos de diseño thirdorder muy detallada de implementación de red, puede tener productos de diseño de primer orden para la gestión y productos del diseño de segundo orden para el examen.

10.2.1 Analogía con un diseño de edificio Puede efectuarse una comparación entre el arquitectura/diseño de una red y la de un edificio. Por ejemplo, en el diseño de un edificio, el diseñador/arquitecto necesita conocer el objetivo general para el edificio (por ejemplo, residencial, comercial, industrial), qué tipo (s) de los ocupantes que del edificio es probable que tenga, aproximadamente cuántos allí serán y qué va a hacer (sus necesidades). El diseño del edificio incluye disposición física del edificio, cómo se utilizará el espacio, cómo los ocupantes se moverse por el edificio y sus necesidades para la construcción de recursos (HVAC, iluminación, energía, agua, sanitarios, salidas, etcetera). El producto del diseño del edificio es un conjunto de planos que ofrecen un diseño físico para toda esta información y mostrar las relaciones entre los componentes del edificio (por ejemplo, donde trade-offs se realizaron entre espacio, energía y otros recursos). Un diseño de red tiene estas mismas características. En vez de los ocupantes del edificio tenemos los usuarios de la red; lo que va a hacer son sus requerimientos (sus aplicaciones y dispositivos, sus flujos de trabajo y tráfico). Arquitectura del edificio se convierte en la arquitectura de red: su

topología y las tecnologías. Mientras que un edificio de arquitectura describe las relaciones entre funciones (espacio, HVAC, eléctrico, plomería, agua, iluminación, ascensores, escaleras, etc.) del edificio, la arquitectura de red describe las relaciones entre las funciones de red (seguridad, red gestión, enrutamiento/abordar, rendimiento, etcetera.). Y como el producto del diseño de un edificio es un conjunto de planos ofreciendo la presentación física de toda su información, el diseño de la red es también un conjunto de planos y diagramas, junto con descripciones textuales de apoyo para la red. Una gran diferencia entre un diseño de construcción y un diseño de red es que allí es a menudo un componente artístico con un diseño de edificio, mientras que raramente es uno para un diseño de red. Puede haber un componente artístico a una red, como cuando forma parte de una exposición, espectáculo o conferencia; sin embargo, la gran mayoría de redes no es vista por sus usuarios.

10.2.2 Diseño de productos Los productos claves de un diseño de red son: • Planos de red • Un plan del componente • Proveedor, vendedor equipos y selecciones de proveedor de servicios de • Trazabilidad • Métricas para medir el éxito del diseño

Planos de red describen los aspectos físicos de su diseño de red: ubicación de los dispositivos de red, servidores, la planta de cable, seguridad física y lugares seguros; Cómo están interconectados los dispositivos, su interfaz tipos y velocidades; así como devicespecific e información específica del servicio. Planos suelen también Mostrar la infraestructura de soporte para la planta de cable: construcción de accesos, conductos, cables y similares. Planos de red pueden consistir en un diagrama único o varios diagramas de la red, dependiendo de sus necesidades y el tamaño de su proyecto. Si el diseño de la red es grande, puede que necesite tener uno o más diagramas de alto nivel que muestran toda la red en detalle, junto con diagramas más detallados que se centran en áreas específicas de la red, como la red WAN, campus LAN, edificios individuales, incluso pisos o habitaciones de un edificio (Figura 10.3). Como parte de los diagramas detallados puede concentrarse en lugares estratégicos de la red, desarrollado durante el proceso de la arquitectura. Esta es la forma tradicional y más común de modelo de red. Para otros casos puede que desee tener varios diagramas detallados que se centran no en áreas específicas de su red, sino en funciones específicas de su red (como ya comentamos durante el proceso de arquitectura). Cuando esto sucede, es útil tener los diagramas como superposiciones (diagramas en hojas claro de plástico), donde puede colocar uno Diagrama encima de otro, para ver cómo y dónde se aplican las funciones dentro de la red, y cómo y dónde se solapan (Figura 1 0.4). puede utilizar los resultados del proceso de arquitectura como punto de partida para desarrollar tales superposiciones.

Figura 10.3 diagramas enfoque en áreas geográficas de una red

Si usted decide describir el diseño de la red como superposiciones de funciones múltiples, entonces cada función puede tener un plan del componente que describe los mecanismos asociados a esa función, interacciones internas entre esos mecanismos, y interacciones externas entre funciones. Planes de componente pueden ser complementarios a los planos de la red, a menudo proporciona información específica de la función que normalmente no estarían en planos. Por ejemplo, un plan del componente que describe la seguridad de la red puede incluir información de configuración de dispositivos de seguridad, tales como sistemas de ACL o VPNs, y donde en la red de cada sistema se puede aplicar. Cada forma de describir la red tiene sus ventajas. Describir áreas geográficas de una red (por ejemplo, redes WAN, LAN) es intuitiva y útil para la instalación, operación, solución de problemas y modificación de esa red. Puesto que estos diagramas tienen todos los dispositivos relevantes representados, es fácil ver la conectividad entre dispositivos y trazar una ruta de acceso en toda la red. Describir las funciones de una red tiene la ventaja de Mostrar todos los dispositivos y servicios de una función particular (por ejemplo, seguridad) juntos en el mismo diagrama. Esto permite que personal de la red más fácil ve donde están esos dispositivos, cómo se facilitará esa función en la red y cómo están interconectados los dispositivos. Por ejemplo, en una estrategia de capas de seguridad de defensa en profundidad, que tenga seguridad diferentes técnicas o grados de seguridad en cada capa. Diagramas funcionales pueden mostrar estas capas de seguridad, que los dispositivos y servicios están en cada capa, y cómo los dispositivos (y capas) de interconexión e interactuaran.

Figura 10.4 diagramas foco en funciones lógicas de la red

Junto con planos y planes del componente, los procesos de análisis y arquitectura de información para proveedores, equipos de proveedor,y selección del proveedor del servicio. En la fabricación de estas selecciones, aplicamos un proceso similar al utilizado para tomar decisiones de arquitectura. Utilizando productos de análisis de red y arquitectura desarrollamos un conjunto inicial de opciones y entonces desarrollar sistemas completos de candidato opciones y criterios de evaluación; recopilar datos para aplicar a las evaluaciones; perfeccionar nuestros criterios de evaluación y desarrollar calificaciones; y luego aplicar criterios y calificaciones para priorizar las opciones de candidato, reduciendo el número de opciones a una o varias opciones óptimas. Una vez que conoce el equipo, vendedores y proveedores de servicios para su diseño, se aplicará los datos de configuración a su diseño, que será utilizado durante las pruebas y la implementación de red. Estos datos consisten en selecciones de información y Protocolo de configuración general y específicos del proveedor (si es necesario). Por ejemplo, conjuntos de mencionó anteriormente como parte del plan de componente de seguridad se consideran detalles de configuración de ACL. Enrutamiento protocolos, como números y enrutamiento específico e información interconexión sería también considerados detalles de configuración. Junto con estos productos también podrás mostrar trazabilidad entre las decisiones de diseño, las decisiones de arquitectura, requisitos y declaración de problema. Se trata de una capacidad de gran alcance que te ayudarán a afrontar cualquier preguntas y desafíos que puedan surgir en cuanto a su diseño.

Como parte de las decisiones sobre su diseño habrá asociado métricas que se utilizan para describir cómo medir el éxito del diseño, de la misma manera que métricas fueron juntadas a los requisitos. Como parte de su trazabilidad también puede mostrar cómo diseño métricas remontar a las necesidades métricas. Métricas de diseño también pueden utilizarse para validar su diseño. Todos los trabajos de arquitectura y análisis hasta este punto proporcionará una excelente base para hacer decisiones de diseño. Esta entrada para el diseño se discute a continuación. La experiencia ha demostrado que muchos proyectos de la red en este momento, iniciar sin el trabajo de análisis y de la arquitectura subyacente. Las decisiones de diseño ad hoc resultante pueden ser desastrosas. Además, he encontrado, mediante la aplicación de los procesos de análisis y arquitectura, diseños de decisiones se convierte en la parte más fácil del proyecto. Conocer los problemas que deben resolverse, los requisitos para el proyecto y la arquitectura de red, las decisiones de diseño pueden realmente el flujo de esta información. Por supuesto, esto es de esperarse: a lo largo de los procesos de análisis y arquitectura nos estamos preparando para tomar decisiones de diseño, por lo que cuando llegamos al proceso de diseño, ya habremos puesto un poco de pensamiento en él.

10.2.3 Entrada para el diseño En este punto en el proceso tenemos un montón de información a utilizar para nuestro diseño. Estos procesos de análisis y arquitectura de ofrecen productos que sirven como entrada a nuestro diseño. Mejor estos productos son, mejor es nuestra entrada, y mejor será nuestro diseño. La basura del"del término adentro, basura hacia fuera" es bastante aplicable aquí. En productos de arquitectura Figura 10.5 se alimenta en las dos partes del proceso de diseño, evaluaciones y el diseño, produciendo una serie de productos de diseño.

Figura 10.5 arquitectura y diseño de productos

A lo largo de este capítulo se discute cómo estos productos se utilizan en el proceso de diseño.

10.3 Proceso de diseño El proceso de diseño consiste en proveedores, equipos y proveedor de servicios de evaluación y diseño de la red. Estos procesos se basan en y añadir detalle a decisiones arquitectónicas. Productos de arquitectura incluyen: • Topología de las • Tecnologías seleccionadas • Tipos/clases de equipo • Apoyo material (por ejemplo, esquemas de trazabilidad) • Relaciones arquitectónicas

• Enrutamiento y direccionamiento • Seguridad • Administración de redes • Rendimiento • Otros (según sea necesario)

Todos estos productos de arquitectura se pueden combinar en la arquitectura de referencia para el proyecto.

Productos de análisis incluyen: • Requisitos • Información sobre el flujo • Declaraciones de problema • Información sobre el servicio

Proveedor, el equipo y proveedor de servicios de evaluaciones se basan en tecnología y equipos selecciones de tipo/clase realizadas durante el proceso de la arquitectura, trabajando hacia el vendedor, proveedor de servicios y selección de equipo para el diseño. Dicha información se formaliza a menudo en documentos como las solicitudes de propuesta (RFP), que son útiles en equipos y contratación de servicios. Hay que recordar que durante el proceso de arquitectura hemos desarrollado un documento similar, una solicitud de información (RFI), que es útil en la recopilación de la detallada del producto y servicio información necesaria para prepararse para las evaluaciones. Diseño de la red combina la topología, la tecnología, tipos de equipos, relaciones y lugares estratégicos para desarrollar planos y planes del componente para su diseño de red. Hasta cierto punto, ambas partes del proceso de diseño se pueden hacer al mismo tiempo y el uso de otros productos (por lo tanto la flecha entre la evaluación y los procesos de diseño en la figura 10.5). Puede que desee incorporar equipo y proveedor de servicios de información de sus evaluaciones en los planos y planes del componente. Así, el diseño de la red es generalmente la última parte del proceso de diseño. Ahora examinemos cada parte del proceso de diseño en detalle.

10.4 Proveedores, equipos y las evaluaciones del proveedor de servicios de El proceso de evaluación aquí presentado puede aplicarse a proveedores y prestadores de servicios, sus equipos y servicios. En general, este proceso consiste en utilizar productos de arquitectura y análisis de red para el desarrollo de un conjunto inicial de opciones (como siembra el proceso de evaluación); realización de debates para el desarrollo de un conjunto completo de opciones de candidatos, junto con criterios para evaluar esas opciones; recopilación y elaboración

de datos para aplicar a las evaluaciones; Criterios de evaluación de refinación y el desarrollo de calificaciones; aplicación de criterios y calificaciones para priorizar las opciones de candidato; y modificar el conjunto de opciones de candidato, con el objetivo de seleccionar al candidato óptimo. Este proceso se muestra en la figura 10.6. Productos de arquitectura siembra los debates de candidatos del proceso Arquitectura de referencia

Seleccionado Priorizadas Candidato Candidatos Candidato DD 1) Candidato 2) Candidato A 3) Candidatos C 4) Candidato B

Modificar el conjunto de calificaciones y

...

Priorización de candidatos

Figura 10.6 proveedores, equipos y proceso de evaluación de proveedor de servicios de

Este es un proceso iterativo. Hay veces cuando un candidato óptimo puede encontrarse con una sola iteración del proceso; otras veces puede tardar dos o tres iteraciones para producir un resultado óptimo. El número de iteraciones depende en parte de la complejidad de las evaluaciones, qué tan bien preparado son, y qué tan bien usted y su equipo de evaluación realizan la evaluación. Como te acostumbras al proceso, podrás obtener resultados con menos iteraciones. Idealmente, una plantilla puede ser desarrollada que puede luego ser aplicada a cada evaluación, el proceso de fabricación simple, predecible y reproducible. Eso es lo que esta sección se esfuerza por ofrecer. Sin embargo, también reconocemos que, según el proyecto, algunas evaluaciones pueden tener sus propias características únicas. En todos los casos he encontrado que este proceso aún puede ofrecer excelentes resultados. Aunque este proceso puede ser aplicado para evaluar proveedores, equipo de proveedores y prestadores de servicios, es importante tener en cuenta que no queremos combinar estas evaluaciones en uno. Separe cada evaluación — no mezcle proveedores, equipo de proveedores y prestadores de servicios, ya que confunden a los evaluadores y complicar demasiado el proceso. Por ejemplo, algunos de los criterios de evaluación de proveedores serán diferentes a los proveedores de servicios, y tratar de aplicar criterios a ambos al mismo tiempo sería problemático. Una parte importante de este proceso es que desarrollas un conjunto detallado de información acerca de cómo hicieron sus decisiones de evaluación. Esta información puede utilizarse para ayudar a reducir o eliminar los desacuerdos que puedan surgir en relación con su proveedor, proveedor de servicios o selecciones de equipo. Estos desacuerdos suelen ser más propensas que los aumentos de presupuesto de diseño.

Example 10.1. Ha sido mi experiencia que una gran parte del proceso de diseño se gasta a menudo resolver protestas trajeron por los proveedores, prestadores de servicios e incluso un subconjunto de los evaluadores, en desacuerdo con una selección (a menudo una selección de proveedores). El proceso de evaluación que

presentamos le proporcionará con un montón de documentación con la que puede resolver o incluso evitar tales protestas. Por ejemplo, he participado en evaluaciones de proveedores donde proveedor A es la elección popular, mientras que el proveedor B tiene la mejor solución técnica. Sin un proceso de evaluación y selección de vendedores, vendedor A habría sido elegido como el de hecho opción, independientemente de su solución técnica inferior. He usado este proceso para ayudar a que sea evidente que el vendedor técnico superior debe ser elegido.

10.4.1 Siembra el proceso de evaluación El propósito de sembrar una evaluación debe iniciar el proceso rápidamente. Siembra consiste en generar una lista inicial de candidatos para la discusión. Una persona, como el jefe de proyecto, o unas pocas personas selectas puede sembrar el proceso de evaluación. Puesto que el objetivo es poner en marcha rápidamente el proceso de evaluación, no quiere pasar mucho tiempo en esto, pero bastante rápidamente armar una lista corta de candidatos (proveedores, prestadores de servicios o equipo, dependiendo de la evaluación) para la discusión. Esta lista consiste en a menudo los candidatos más obvios. ¿Por qué es esto necesario? He encontrado que es mucho más fácil de generar discusión y desarrollar opciones cuando algunas de las opciones ya están sobre la mesa. Esto tiende a enfocar el grupo y les da algo para trabajar hacia (o contra). Algunos o todos los productos de análisis y arquitectura que se muestra en la sección 10.3 deben ser directamente aplicables para iniciar el proceso de evaluación. Podemos utilizar estos productos para determinar un conjunto inicial de candidatos. Por ejemplo, el proceso de la arquitectura nos ofrece tecnologías de red y topología de red que fueron seleccionados para el proyecto. Las tecnologías de red seleccionados pueden estar disponibles sólo en un subconjunto de los proveedores (y su equipo) y pueden ser apoyadas por un subconjunto de los proveedores de servicios. Asimismo, la topología de red seleccionada puede ser apoyada sólo por un subconjunto de los proveedores de servicios. Además, sólo algunos proveedores de servicio pueden ser capaces de llegar a los lugares estratégicos para la arquitectura de red. Por ejemplo, una ubicación estratégica reside en una ciudad que no está disponible para algunos proveedores, o puede ser prohibitivo para ellos dar servicio a esos lugares. Las relaciones arquitectónicas, junto con ubicaciones estratégicas, pueden haber producido equipos específicos tipos o clases de ser elegidas. Por ejemplo, lugares estratégicos que requieren alto rendimiento de enrutamiento, seguridad y administración indican la necesidad de equipos de mayor escala (e.g., equipo carrier class) donde podemos combinar estas funciones, o la necesidad de múltiples instancias y tipos de equipos para la distribución de estas funciones. La clase o tipo de equipo elegido puede indicar que un determinado conjunto de proveedores, tal vez también pedazos particulares de equipo. También tenemos los productos del análisis de red, los requisitos y especificaciones de flujo, que puede utilizarse para ayudar a determinar los candidatos iniciales para la evaluación. La siembra del proceso de evaluación resulta en que algunos vendedores de candidatos, opciones de equipos proveedor o los proveedores de servicios en el siguiente paso en este proceso, discusiones con los participantes del proyecto.

10.4.2 Debates de candidatos Habiendo desarrollado una breve lista (semilla) de los candidatos, quieren usar esa lista para generar una lista más completa de los candidatos, así como comenzar a desarrollar un conjunto de criterios que podemos utilizar para la evaluación. Mientras que una o algunas personas pueden desarrollar la lista de semillas, la lista completa debe involucrar a un grupo mucho más grande de participantes, incluyendo el equipo del proyecto, seleccione los usuarios potenciales de la red, personal técnico, gestión y las partes interesadas. El equipo de evaluación debe representar la escala y el alcance de su proyecto. Utilizar la semilla como punto de partida, las discusiones se llevan a cabo, a menudo con una pizarra o equivalente, de la Web para ampliar esta lista. En este punto del proceso es mejor incluir todos los candidatos, incluyendo obviamente inferiores y rechazar en la priorización y selección, en lugar de rechazarlos directamente. Aunque la lista se vuelve poco manejable, se puede ser rápidamente pared hacia abajo una vez que sus criterios y valoraciones se han desarrollado. De esta manera será capaz de mostrar que usted considera un considerable número de opciones, junto con razones para rechazarlas. Esto puede ser útil más adelante si alguien impugna su selección por uno que pasa a ser parte de tu lista de rechazos. Además, puede encontrar que una de su opciones no-tan-obvio resulta ser uno de los mejores. Junto con el conjunto completo de los candidatos tendrá que desarrollar el conjunto de criterios de evaluación. Ejemplos de criterios de evaluación se muestran en la figura 10.7. El juego también es probable que contendrá los criterios de evaluación específicos para su proyecto, su red y su organización. En este punto en el proceso no debe usar estos criterios para evaluar a sus candidatos. Todavía tenemos que afinar los criterios, así como desarrollar los pesos para el Criterios de evaluación 1

Costos de

2

Tecnologías

3

Rendimiento

4

Riesgos

Figura 10.7 un conjunto ejemplo de criterios de evaluación inicial

criterios, antes de aplicarlas. Pero incluso antes de tenemos que realizar alguna investigación y recopilación para apoyar la evaluación de datos.

10.4.3 Recopilación de datos Ahora que usted ha desarrollado un completo (o casi completo) a los candidatos del (proveedor, equipo de proveedor de servicios), usted necesita recoger y elaborar datos que serán útiles para su evaluación. Fuentes y tipos de datos comunes son: • Discusiones con grupos internos y externos

• Conversaciones con proveedores o prestadores de servicios • Evaluaciones independientes (de terceros) de proveedores, equipos y proveedores de servicios • Modelado y simulación • Información de las evaluaciones de riesgos

Discusiones con grupos internos y externos pueden proporcionar información además el candidato discusiones. El propósito de estas discusiones es ampliar la cantidad de información hablando con más usuarios y personal y en mayor detalle. Grupos externos pueden ser capaces de relacionar sus experiencias con vendedores de candidato, equipo de proveedores y prestadores de servicios. Esto es especialmente útil cuando el diseño incluye las tecnologías o equipos que son nuevos, pero que otros tienen experiencia (por ejemplo, implementación y experiencia con IPv6). Grupos externos pueden ser otras organizaciones como la suya, o grupos con un interés común, tales como grupos o foros técnicos. Puesto que ahora tenemos una lista de candidatos, debates con proveedores o prestadores de servicios en esa lista son a menudo útiles para obtener información específica acerca de cada proveedor, el proveedor de servicios o el equipo. Estas discusiones también pueden ser útiles en el aprendizaje de lo que cada uno es capaz de hacer para su proyecto: prestación de servicios de valor agregados, acceso a laboratorios, pruebas y validación y precios competitivos son algunos ejemplos. Sin embargo, vendedores y proveedores de servicios no se debe acercar demasiado a la evaluación. Están motivados para representar sus productos y servicios en la mejor luz y pueden intentar dirigir la evaluación en su dirección. Por lo tanto, es mejor mantener estas discusiones aisladas de las evaluaciones (es decir, no invitarlos a las reuniones donde se discuten las evaluaciones). Junto con las anteriores discusiones, a veces es útil para obtener evaluaciones independientes (terceros) de proveedores, equipos y proveedores de servicios. Evaluaciones independientes proporcionan un estudio prospectivo que a menudo es diferente de qué grupos internos, proveedores, y darán a los proveedores de servicios. Como grupos externos, asesores independientes pueden ser capaces de proporcionar que con la implementación y funcionamiento experimenta con tecnologías y equipos que son nuevos para usted. Para las evaluaciones independientes tiendo a elegir pequeñas empresas o personas (consultores) en lugar de grandes consultoras. Modelado y simulación de la totalidad o parte de la arquitectura de red pueden proporcionar información valiosa para su evaluación. Por ejemplo, puede utilizar modelos informáticos para hacer comparaciones de cómo la red llevará a cabo utilizando proveedores de servicio diferente, basados en sus servicios y sus infraestructuras. Ya puede tener parte de esta información si hiciste modelado y simulación para refinar el análisis de redes o la arquitectura. Además de lo anterior, toda la información de las evaluaciones de riesgos que es aplicable a los proveedores o prestadores de servicios puede ser útil en las evaluaciones. Su evaluación de riesgo realizada temprano en el proceso de análisis, puede revelar ciertos riesgos para su proyecto. Uno o más de estos factores de riesgo pueden ser aplicables para su evaluación. Por ejemplo, el proyecto puede ser adverso al riesgo de la aplicación de un nuevo protocolo, tecnología o servicio. Proveedores o prestadores de servicios aplican uno de estos, puede utilizarse como parte de su evaluación.

Toda esta información generalmente es compilado como un documento en apoyo a las evaluaciones y es llevado adelante en el refinamiento de los criterios y el desarrollo de calificaciones. Además, esta información puede ser muy útil en la elaboración de documentos oficiales necesarios en la adquisición e implementación de su diseño. Un ejemplo de ello es el desarrollo de una solicitud de compra (RFP) para productos y servicios. Por ejemplo, utilizando el conjunto de criterios de evaluación inicial de la figura 10.7, recopilación de datos probablemente nos permitiría ampliar que conjunto basado en el aporte de varias organizaciones. Vendedores probablemente sería capaces de añadir tecnología y normas específicas información, mientras seamos capaces de aprender acerca de los riesgos de otras organizaciones que ya han realizado proyectos similares. Seamos capaces de aprender los detalles específicos en cuanto a rendimiento, de estas mismas organizaciones o de grupos que hacen equipo y prueba del sistema.

10.4.4 Criterios de refinamiento y desarrollo de calificaciones Ahora que usted tiene información adicional con respecto a Tu criterio (desde el ejercicio de recopilación de datos), puede utilizar esta información para refinar los criterios. A menudo, en reunir y desarrollar datos, aprendemos que hay algunos nuevos criterios que se deben agregar; que algunos criterios existentes no son tan apropiados como primer pensamiento y tal vez debería eliminarse; o que algunos criterios deben ser modificados según la nueva información. El resultado es un conjunto de criterios de evaluación refinado y mejor. Para aplicar estos criterios a su lista de candidatos, debe tener alguna manera de comparar y contrastar a los candidatos. Esto se hace comúnmente con un sistema de calificaciones. Calificaciones muestran cómo los candidatos comparan a uno con el otro. Calificaciones se aplican con criterio (que ya tienes) y los pesos que muestran la importancia relativa de cada criterio. En esta sección estamos preocupados con el desarrollo de pesos de nuestros criterios. Aunque esta es una de las partes más subjetivas del proceso, es necesaria para hacer selecciones de la lista. En nuestro ejemplo teníamos los criterios iniciales siguientes: costos, tecnología, rendimiento y riesgos. De nuestros datos nos enteramos que los costos deben estar separados en los costos iniciales y recurrentes, y que se deben agregar otros criterios: cumplimiento de los estándares, servicios, operaciones y escalabilidad. Si nuestra semilla conjunto de dos candidatos en cinco candidatos de diseño, nuestra carta de evaluación sería algo como la figura 10.8. Tenga en cuenta que tenemos una columna de pesos relativos y una fila de total de las calificaciones para cada candidato, que aún tenemos que completar. En esta figura tenemos nueve criterios. Cada criterio se dará un peso basado en la importancia de ese criterio a la evaluación. Esto se determina a través de la discusión en grupo, que puede incluir la votación sugeridos pesos. La gama de pesos que se aplican no es tan importante como mantener la consistencia a lo largo de su evaluación. Una gama común de pesos en el conjunto de criterios es 0 – 1, donde 0 significa que ese criterio no tiene ninguna importancia a su evaluación, 1 significa que tiene la mayor importancia a su evaluación, y cualquier valor en el medio indica el grado de ese criterio de importancia. (Tenga en cuenta que usted podría decidir que todos los criterios son iguales, en cuyo caso no necesita asignar pesos o usted podría dar a cada criterio un peso de 1.)

En nuestro ejemplo sería tomar los datos recogidos hasta el momento, junto con nuestros refinados sistemas de criterios y candidatos y llevar a cabo una discusión acerca de cómo el peso de cada criterio. Utilizando un rango de 0 – 1, figura 10.9 muestra cómo podrían aplicarse los pesos. Candidatos Criterios de evaluación

1

Costos iniciales

2

Costos recurrentes

3

Tecnologías

4

Peso relativo

Candidato

Candidato

Candidato

Candidato

Candidato

1

2

3

4

5

Cumplimiento de las normas

5

Riesgos

6

Rendimiento

7

Servicios disponibles

8

Operaciones de

9

Escalabilidad

Estadísticas totales de candidato

Figura 10.8 un refinado conjunto de criterios de evaluación

Peso Criterios de evaluación

relativo (01)

1

Costos iniciales

0.8

2

Costos recurrentes

1.0

3

Tecnologías

0.5

4

Cumplimiento de las

Candidatos

0.2

normas 5

Riesgos

0.9

6

Rendimiento

0.8

7

Servicios disponibles

0.2

Candidato 1 Candidato 2 Candidato 3 Candidato 4 Candidato 5

8

Operaciones de

0.5

9

Escalabilidad

0.1

Estadísticas totales de candidato

Figura 10.9 ha añadido un conjunto de criterios de evaluación con pesos relativos

En esta figura los costos recurrentes se ponderan más alto, seguido de los riesgos, costos iniciales y rendimiento. Operaciones y la tecnología son pesados en el medio de la escala, mientras que el cumplimiento de los estándares, servicios disponibles, y escalabilidad se cargan menos. Mirando esta tabla de comparación, puede ver la importancia que el equipo de evaluación pone en cada criterio. Es útil escribir cómo llegaste a cada peso y tenga esto como parte de su documentación. Si le piden alguna vez por qué ciertos criterios se ponderan más que otros, usted será feliz de tenerlo documentado. He encontrado que la memoria no sirve bueno aqui: ha habido veces cuando estaba seguro de que me acordaría de las razones de un peso (parecía obvio al tiempo), sólo para olvidar cuando se le preguntó más adelante. Hay formas adicionales de hacer pesas para los criterios. Como comentamos durante el proceso de análisis, algunas de las características que podemos aplicar criterios son urgencia, importancia y relevancia. Urgencia es una medida de cómo tiempo crítico es el criterio; importancia es una medida de cómo importante es el criterio para este proyecto; y relevancia es una medida de la idoneidad de este problema al proyecto. La característica por defecto es de importancia. Cada criterio puede ser evaluado en términos de urgencia, importancia y relevancia y un peso asignado al criterio que se basa en todas las tres características. A continuación, los candidatos pueden ser evaluados como en el ejemplo anterior. En la siguiente sección se utilizan nuestros pesos con calificaciones basadas en cómo cada candidato las tarifas en relación a uno con el otro para un criterio determinado.

10.4.5 Clasificación y priorización Armados con nuestros criterios y los resultados de nuestros ejercicio de recopilación de datos que ahora desarrollar calificaciones para cada candidato. Como en desarrollo de la primera serie de pesos, esto debería ser un esfuerzo de grupo que incluye sus mejores técnicos y ejecutivos tomadores de decisiones. El tamaño de un grupo de evaluación es importante, no desea que un grupo tan grande que no consigue lograr ni uno tan pequeño que las decisiones tomadas por el grupo será protestada por otros en su organización.

Example 10.2. Mi experiencia es que un tamaño de grupo en algún lugar entre seis y doce es óptimo para la fabricación de este tipo de decisiones. Curiosamente, esto funciona desde pequeño a diseños muy grandes.

Un requisito importante del grupo de evaluación es que no hay vendedores o prestadores de servicios presentes. Esto puede parecer obvio, pero es sorprendente la frecuencia con que son capaces de involucrarse. Claramente, para el desarrollo justas y equilibradas de decisiones es mejor dejarlos. Usted debería haber ya recibido toda la información relevante de los proveedores y prestadores de servicios durante el proceso, antes de desarrollar y aplicar índices de recopilación de datos. Para continuar con nuestro ejercicio, tenemos nuestro grupo de evaluación juntos junto con nuestra carta de evaluación. Entonces tenemos que acordar una escala para nuestra calificación. Una gama común es la misma gama usada anteriormente, 0 – 1, donde 0 significa que el candidato es menos relevante para ese criterio y 1 significa que es más relevante. Otros comunes son 1 a 5 o 1 – 10, donde un peso de 1 significa que ese candidato es el peor o menos relevantes para ese criterio y 5 (o 10) significa que ese candidato es el mejor o más relevantes para ese criterio. Usted podría utilizar estos rangos para clasificar a los candidatos, dando al mejor candidato (de acuerdo con ese criterio) a 1, lo siguiente mejor a 2 y así sucesivamente. Ampliar la escala, o revertir los números (de modo que 10 es el peor o menos relevantes) es totalmente subjetivo. Sin embargo, es importante que el grupo de evaluación está de acuerdo en la escala. Si tienes problemas con esto, indica que va a tener problemas durante las evaluaciones. Digamos que para este ejemplo elegimos una escala de 1 a 5, 5 siendo el mejor y 1 el peor. A continuación tomar uno de los criterios de evaluación (por ejemplo, costes) y discutir cada opción de diseño en base a esto. Esto debe ser un proceso democrático, donde cada persona tiene la oportunidad de expresar su opinión y votar en cada candidato. El líder de grupo o Gerente de proyecto rompería lazos si es necesario. Para una discusión sobre los gastos que tengamos información de costo (para el diseño de cada candidato) que fue proporcionado por una evaluación independiente, de otras organizaciones que están desplegando un diseño similar, desde nuestra propia experiencia o de los vendedores y el servicio proveedores de sí mismos. Usted debe ser capaz de recabar la información costo y utilizarla para determinar una calificación relativa para cada candidato de diseño. Rellenar la tabla de evaluación con calificaciones para todos los candidatos para el criterio de coste y luego hacer lo mismo para los otros criterios. Una vez que han dado calificaciones a cada uno de sus candidatos a través de todos los criterios, puede multiplicar el peso de cada criterio con la calificación dada a cada candidato. El resultado sería algo parecido a figura 10.10. En este ejemplo cada candidato se clasifica desde 1 (peor) a 5 (mejor) para cada criterio. Las calificaciones se muestran como el primer número en cada cuadro de evaluación. Luego se multiplica cada calificación por peso relativo de ese candidato, dando como resultado una calificación ponderada. Estas calificaciones ponderadas se muestran como el segundo número en cada cuadro de evaluación. Las clasificaciones y calificaciones ponderadas para cada candidato se suman, como se refleja en los totales del candidato en la parte inferior de la figura. Aunque se muestran todos los resultados de las calificaciones ponderadas y sin ponderar (para ilustración), sólo la calificación ponderada sumaron y aplicada a la evaluación. Tener ambos ponderados y sin ponderar calificaciones en una evaluación real sería confusos. Peso Criterios de evaluación

Candidatos

relativo (01)

Candidato 1 Candidato 2 Candidato 3 Candidato 4 Candidato 5

1

Costos iniciales

0.8

3/2.4

5/4

4/3.2

2/1.6

1/0.8

2

Costos recurrentes

1.0

4/4

5/5

3/3

1/1

2/2

3

Tecnologías

0.5

3/1.5

4/2.0

1/0,5

2/1.0

5/2.5

0.2

4/0.8

1/0.2

3/0.6

2/0.4

5/1.0

4

Cumplimiento de las normas

5

Riesgos

0.9

3/2.7

4/3.6

1/0.9

5/4.5

2/1.8

6

Rendimiento

0.8

4/3.2

5/4.0

2/1.6

1/0.8

3/2.4

7

Servicios disponibles

0.2

5/1.0

1/0.2

3/0.6

2/0.4

4/0.8

8

Operaciones de

0.5

3/1.5

5/2.5

4/2.0

2/1.0

1/0,5

9

Escalabilidad

0.1

5/0.5

1/0.1

3/0.3

2/0.2

4/0,4

34/17.6

31/21.6

24/12.7

19/10.9

27/12.2

Estadísticas totales de candidato

Figura 10.10 un conjunto de calificaciones de los candidatos

Aviso de esta figura que, si seguimos la clasificación de la ponderada (primeros números), Candidate 1 tiene la puntuación más alta. Sin embargo, usando la calificación ponderada, candidato 2 recibe la puntuación más alta. Esto es porque el candidato 2 tiene las calificaciones más alta para aquellos criterios que tienen los pesos más altos. Por lo tanto, aplicar pesos le permite concentrar la evaluación en las áreas de importancia para su proyecto. Finalmente, es útil tener una forma de determinar cuando la clasificación de la general (Resumen) es tan estrecha que debe declarar un empate y qué hacer cuando eso ocurre. Mejor práctica es declarar un empate cuando los candidatos están dentro de unos pocos puntos porcentuales de cada uno. Al desarrollo de calificaciones y aplicación a los candidatos se hacen bien, ayuda a tomar la política en el proceso de evaluación. Haber clasificado a nuestros candidatos, ahora es tiempo para perfeccionar el conjunto de candidatos, con el objetivo de seleccionar el proveedor óptimo, equipo o proveedor de servicios para nuestro proyecto.

10.4.6 Modificar el conjunto de candidatos Ahora tienes una tabla de evaluación que muestra cómo cada candidato de diseño de red realizado contra varios criterios. Pesos fueron desarrollados para el conjunto de criterios. Cada candidato recibió una calificación para cada criterio, que luego se multiplicaron por el peso de ese criterio para formar índices ponderados. La calificación ponderada se combinaron para formar un total para cada candidato. El resultado de la evaluación es un conjunto de clasificaciones general o resumen que combina la calificación individual para cada candidato. Deltas Rango

1

Candidato

Candidato 2

Relativa

Total

0

0

2

Candidato 1

-4

-4

3

Candidato 3

–4.9

–8.9

4

Candidato 5

– 0,5

–9.4

5

Candidato 4

–1.3

–10.7

Figura 10.11 clasificaciones de los candidatos después de la evaluación

Resumen calificaciones se utilizan para priorizar el conjunto de candidatos. Por ejemplo, de nuestra carta anterior de evaluación sería obtener la priorización que se muestra en la figura 10.11. Esta figura muestra el ranking de cada candidato, junto con la relativa diferencia en las calificaciones de ese candidato y la siguiente más alto en rango (delta relativa) y la diferencia en grados entre ese candidato y el candidato superior (total delta). O delta puede utilizarse para determinar si un candidato debe descartarse del conjunto, o si se debe declarar un empate. Si, para este ejemplo, habíamos decidido que un candidato tenía que ser en un punto del siguiente candidato superior (cerca de 5% de la calificación Resumen de candidato 2) para poder declarar un empate, pudimos ver desde los deltas relativos que no hay candidatos son lo suficientemente cercanos para ser t IED, y que el candidato 2 es el claro ganador. Con un conjunto prioridad puede eliminar a candidatos con malas calificaciones, con el objetivo de lograr a un solo candidato óptimo. Generalmente se elige un solo candidato cuando es claramente superior, es decir, cuando sus calificaciones son significativamente mejores que los otros candidatos. Por lo general, en una primera ejecución de la evaluación no habrá un candidato claramente superior; en cambio, puede haber pocos o varios, dependiendo en parte de cómo muchos candidatos comienzan con. Cuando el proceso de evaluación produce más de un candidato superior, otra iteración del proceso de evaluación debe realizarse en este conjunto reducido. Sucesivas iteraciones del proceso de evaluación comienzan con un debate de candidatos continúan a través de la recopilación de datos, refinamiento de criterios, desarrollo de calificaciones, calificaciones y priorización, y otra modificación de los candidatos. Una ventaja de hacer otra iteración del proceso de evaluación es que tiene la mayoría de los trabajos: los conjuntos de datos y criterios de evaluación. El trabajo realizado en cada iteración sucesiva mejora esa información y debe resultar en priorizaciones y clasificación más clara y mejor. Finalmente, la evaluación debe resultar en un solo candidato superior.

Example 10.3. La experiencia demuestra que a menudo uno o dos iteraciones del proceso de evaluación dará lugar a un solo ganador. Si dos evaluaciones y todavía tiene más de un candidato de izquierda (o lo que es peor, varios candidatos de la izquierda), debe reevaluar sus datos de evaluación y cómo se realizan las evaluaciones.

10.4.7 Determinar el orden de las evaluaciones

Recuerde que este proceso puede utilizarse para seleccionar proveedores, su equipo y proveedores de servicios para su diseño, y que se aplicará este proceso a un único tipo de evaluación a la vez. Sin embargo, puede ser información se reunieron para una evaluación que puede utilizarse también para las otras evaluaciones. Por ejemplo, información del vendedor, que se reunieron para evaluación de proveedores, también puede ser útil para evaluar elementos específicos de equipos del proveedor. Asimismo, los proveedores de servicios pueden utilizar equipos para redes similares a las que está evaluando. Esto puede ser particularmente importante desde la perspectiva de servicio end-to-end y compatibilidad. Esto implica que puede haber un orden óptimo para las evaluaciones. De hecho, puede ser a su ventaja para la secuencia de sus evaluaciones para que pueda reutilizar y aprovechar información. Acommonordertoevaluations (asindicatedbythetitletothissection) es el vendedor, vendorequipment, andserviceprovider. Thelogicfordoingthisisasfollows: 1. Puede elegir qué proveedores que desee para su diseño antes de hacer selecciones específicas para equipos de red. Opciones de proveedores pueden influir fuertemente en selección de equipos. Por supuesto, hay una discusión contraria a esto: que no se debería hacer selecciones proveedor influyen en la elección de los equipos. Sin embargo, típicamente sus selecciones para vendedores y equipos corren menos flojamente acoplados. 2. Comprensión que va a adquirir el equipo red le ayudará a tomar mejores decisiones con respecto a los proveedores de servicios. Una alternativa es evaluar proveedores y prestadores de servicios al mismo tiempo. Esto no significa que se combinan sus evaluaciones, pero más bien realizarlas por separado durante el mismo período de tiempo.

10.5 Diseño de la red Diseño de la red toma decisiones topología y tecnología; decisiones de arquitectura y diseño; proveedor, equipamiento y opciones de proveedor de servicios; y lugares estratégicos; y de estos se desarrolla diversas opiniones de su diseño de red planificada, incluyendo detallados diagramas lógicas, físicas planos y planes del componente específico de cada función. Todos los productos de este proceso también deberían mostrar las partes de la red existente que se incorporará en el nuevo diseño.

10.5.1 Diagramas de lógicas Lógicas diagramas muestran las relaciones entre dispositivos de red y conectividad. Las relaciones muestran cómo dispositivos pueden interactuar uno con el otro, cómo pueden trabajar juntos para brindar servicio y soporte en la red, y lo que puede esperar de ellos. Por ejemplo, podría tener un diagrama lógico que muestra los routers en la red, o mostrando sólo los routers de frontera, o sólo las interfaces a todas las redes externas. Estos diagramas también pueden incluir dispositivos de seguridad y cómo se conectarán a los routers, proporcionando información acerca de cómo los routers y dispositivos de seguridad trabajarían juntos en una interfaz externa. Esquemas que se centran en relaciones lógicas lo hacen a expensas de exactitud en las descripciones físicas (es decir, la precisión de localización). Dichos diagramas pueden proporcionar correlaciones aproximadas entre los dispositivos y sus ubicaciones físicas; sin embargo, no proporcionan una representación exacta de espacio físico. Me refiero a estas descripciones como

diagramas lógicos y no planos, ya que no proporcionan la precisión espacial tradicional y nivel de detalle en planos. Diagramas que muestran relaciones lógicas entre los dispositivos son muy útiles como compañeros a planos de red, o como los bosquejos tempranos de planos. Figura 10.12 es un ejemplo de un diagrama de red. Esta figura es un ejemplo de un armario de comunicaciones. Muestra los tipos de dispositivos de red previstos para ese armario, y cómo están conectadas lógicamente. Por ejemplo, del diagrama se puede decir que existen varios firewalls y switches en el armario de comunicaciones. También se puede ver la conectividad entre dispositivos y las redes locales a Internet. En esta etapa, sin embargo, no describe las selecciones de equipo o proveedor reales, rutas de cable o tipos o la disposición física de los dispositivos en racks o estantes. Esquemas como estos son útiles para la planificación de propósitos; sin embargo, no se detalla lo suficiente como para considerarse planos. Otro ejemplo de un diagrama lógico se muestra en la figura 10.13. En lugar de describir un lugar en particular, este diagrama muestra la interconexión lógica de dispositivos de a través de una red. Este diagrama es muy útil describe el

Figura 10.12 un diagrama lógico de un Closet de comunicaciones

jerarquía de las conexiones, que pueden asignarse fácilmente a los flujos de tráfico en la red.

10.5.2 Planos de red Como se mencionó al principio de este capítulo, planos de red describen detallados aspectos físicos de su diseño de red: ubicaciones de los dispositivos de red, servidores, planta de cable, seguridad física y lugares seguros; Cómo dispositivos deben estar interconectados, tipos de interfaz y velocidades; así como información de configuración específica del dispositivo y específico del servicio. Hay mucho más detalle en un plan de acción que hay en un diagrama lógico. Planos de red pueden consistir en un mismo diagrama o conjunto de diagramas de red, dependiendo del tamaño de la red. Si su diseño de red es grande usted puede preferir tener

diagramas de alto nivel que muestran toda la red en detalle, junto con diagramas más detallados que se centran en áreas específicas de red, tales como áreas geográficas: un pálido, campusLANs, networkbackbones, individualbuildings, evenfloorsorrooms de un edificio. Uno de los focos de planos puede estar en lugares estratégicos en la red. Desarrollo de planos de red consiste en asignar lugares estratégicos de la red en plantillas de red; aplicación de topología y tecnología de la información; y añadiendo las selecciones de los equipos de red y servicios. Aunque estos pasos se describen secuencialmente en esta sección, es posible (y a menudo deseable) para aplicar simultáneamente dos o más de ellos. Dependiendo de su

Figura 10.13 A la lógica del diagrama que muestra la interconexión de dispositivos en una red

diseño y hasta qué punto a lo largo de usted con su proceso de selección, su tecnología de opciones pueden ser fuertemente acopladas a una o más topologías. También, si opciones de equipo se han hecho en este punto, casi siempre se juntan a opciones de tecnología. Así, encontrará que puede asignar equipo y tecnología en cada ubicación estratégica como paso a través de la topología. Asignación de lugares estratégicos Desarrollo de planos de red comienza con recoger la información física acerca de la red (diagramas de habitaciones, pisos, edificios y campus, ubicaciones de planta física, habitaciones/armarios de comunicación y salas de informática y el servidor). Esta información proporciona las plantillas que se describen detalles de la red. Figura 10.14 se muestra un ejemplo de un diagrama que se ha utilizado como base para un modelo de red. Si no dispone de tales diagramas, necesita desarrollar sus propias plantillas para el plan de la red. Si está disponible, puede utilizar edificio o campus modelos como base para sus plantillas. Usando estas plantillas de mapa de los lugares estratégicos de la red. Queremos identificar lugares estratégicos como son de particular importancia para el diseño de la red. Desde una perspectiva financiera, estos lugares están probables que se aplique una serie de funciones de red y por lo tanto donde nos puede interesar múltiples, dispositivos de alto rendimiento (y más caros). Como tal, probablemente pasaremos una mayor proporción de nuestro presupuesto de dispositivo en estos lugares. Desde una perspectiva de tiempo, normalmente planeamos desarrollar estos lugares en primer lugar, ya que son clave para el desarrollo de toda la red. Desde una perspectiva topológica, lugares estratégicos suelen ser lugares donde se aplica la jerarquía. Jerarquía se produce en la red a través de capas de la

Figura 10.14 un ejemplo de un diagrama físico para una pequeña empresa

red para segmentar y aislar partes de la red y agregación de tráfico fluye mientras se mueven a través de la red. Puesto que normalmente impactamos más flujos de tráfico (y así más usuarios de esos flujos) en lugares estratégicos, tenemos el potencial para impactar más usuarios en estos sitios. Debería ya haber identificado probables ubicaciones estratégicas para su red durante el proceso de la arquitectura y debe estar preparado para aplicar sus esquemas físicos. Si no, en este punto en el proceso usted deberá determinar si tiene lugares estratégicos en la red y, si es así, donde están. Algunos ejemplos de posibles lugares estratégicos basados en función de la red son lugares donde: • Puntos límite se producen entre las células/las zonas de seguridad. • Principales componentes de control y gestión se ubican, sobre todo cuando se trata para que no

sean funciones OAM. • Múltiples mecanismos de funcionamiento, tales como QoS y políticas, son necesarias. • Diferentes clases o routers o conmutadores de interfaz. Esto indica una agregación de rutas,

redes y flujos de tráfico. Esto también es un punto estratégico basado en la jerarquía. • Múltiples protocolos de enrutamiento (EGP y IGPs) coexisten. • Múltiples funciones de red (por ejemplo, seguridad, gestión de red, rendimiento, distribución)

coexisten. Más que estos ejemplos son ubicados, más probable es que esa situación es de importancia estratégica. Algunos ejemplos de posibles ubicaciones estratégicas basados en jerarquía están en: • Interfaces LAN, MAN y LAN – WAN • Interfaces externas de los edificios. • Interfaces externas de un campus (esto también puede ser una interfaz LAN, MAN o WAN-LAN) • Interfaces entre las redes de acceso y una red LAN • COMO límites

Lugares estratégicos comunes se encuentran en interfaces externas de la red, donde la red se conecta a otras redes, como a otros sistemas autónomos o a Internet. En muchas redes de pequeñas y medianas empresas, esto se derrumba a una única interfaz externa (aunque múltiples interfaces externas pueden ser necesarias cuando se requiere la diversidad de ruta externa). Estos puntos son estratégicos por varias razones: en primer lugar, son a menudo el límite más importante en la red (y pueden requerir diferentes protocolos para cada interfaz, interno y externo); en segundo lugar, a menudo requieren la presencia de todas las funciones principales de la red; en tercer lugar, jerarquía está a menudo presente, en que se agregan los flujos de tráfico en estas localidades. Esto puede resultar en co localización relativamente alto rendimiento routers,

dispositivos de seguridad, monitoreo y administración de red y dispositivos de funcionamiento de este sitio. Otro conjunto de lugares estratégicos comunes es en las interfaces a la red troncal. Aunque tales interfaces se encuentran dentro de su red, pueden ser lugares donde se encuentran los límites de seguridad y jerarquía se produce por agregación de tráfico de flujo. A menudo seguridad, rendimiento y mecanismos de enrutamiento se aplican a ambos lados de dichas interfaces. Memoria de su análisis de flujo backbones de red generalmente proporcionan transporte únicamente a los flujos de tráfico transitorio, mientras que redes que conectan a y están conectadas por una columna vertebral originan y poner fin a los flujos de tráfico. Con esta definición podemos aplicar diversos mecanismos para flujos de tráfico transitorios y no transitorios. Por ejemplo, podemos elegir aplicar servicios diferenciados como el mecanismo de QoS de IP en la columna vertebral, donde podemos asignar las clases de tráfico a los agregados de los flujos de tráfico transitorio. Sin embargo, como los flujos de tráfico más cercanos a sus creaciones y destinos, queremos ser capaces de aplicar QoS de forma más granular, posiblemente por dirección IP, por puerto o por el flujo de tráfico. Interfaces de la red troncal son ubicaciones lógicas para tal dualidad de función, y esto también hace que sean estratégicas desde una perspectiva topológica. Desde una perspectiva de planificación, lugares que incorporan varios de los ejemplos anteriores son estratégicas en que son lugares claves para el crecimiento futuro de su sistema. Desde lugares estratégicos tienen todas o algunas de las funciones de seguridad, rendimiento, monitorización, enrutamiento y otros, son excelentes lugares para los servicios que pueden tomar ventaja de coubicación con estas funciones. VoIP, vídeo IP, mensajería y una variedad de aplicaciones distribuidas son ejemplos. Porque lugares estratégicos de la casa a una serie de dispositivos de red importante, usted quiere asegurarse de que sus entornos físicos proporcionan apoyo adecuado. Esos lugares deben proporcionar un relativamente alto grado de seguridad física, acondicionamiento eléctrico y aire acondicionado. Puede que necesite mejorar el ambiente físico de armarios de cableado, salas de comunicaciones, salas de computación y similares como parte de la implementación de la red cuando se identifican como lugares estratégicos en la red.

Example 10.4. En la visita a un cliente para realizar una revisión de sitio de su infraestructura de red, me sorprendió encontrar una ubicación de red estratégica donde equipos críticos (routers y dispositivos de seguridad) estaban sentados en las mesas, en medio de una sala abierta, en 2 a 3 pies de agua estancada . Había ningún acceso restringido (las puertas estaban abiertas), no de compartimento de cableado (de hecho, los cables se cuelgan del techo) y no hay consideraciones especiales de la HVAC. No hace falta decirlo, la renovación de este lugar era de primordial importancia en el nuevo diseño de la red.

Es posible que haya no obvios lugares estratégicos en la red. Si durante los procesos de la arquitectura y requisitos, no puede identificar los posibles lugares estratégicos enumerados anteriormente, usted puede estar desarrollando una red topológicamente y estructuralmente homogénea. Esto es raro, sin embargo, y debe tenerse cuidado para asegurar que no han faltado posibles ubicaciones.

Aplicación de selección de la topología Sus opciones de lugares estratégicos deben asignar a la topología seleccionada para la red. Las topologías implican interfaces jerárquicas, que indican agregación de tráfico de flujo y el potencial para identificar lugares estratégicos. Su elección de la topología describe la estructura de alto nivel de la red y consiste en los lugares principales que apoyan esta estructura y la interconexión entre estos dos puntos. La Ubicación del término se utiliza aquí, como puede haber mucha flexibilidad en la descripción de lo que está conectado en una topología. Cada ubicación en una topología puede ser tan grande como una red o tan pequeños como un solo dispositivo. Típicamente, una topología consiste en dispositivos de red (routers o switches), posiblemente co-ubicada con servidores y dispositivos de seguridad, la supervisión y el rendimiento. Los conjuntos de (soporte, red, servidor) dispositivos en cada sitio que son interconectados por la topología son lo que se refieren a como lugares y se muestran en la figura 10.15. Interconectividad describe cómo están conectados los lugares. Esto puede ser tan básico como que describe las rutas físicas, o puede incluir la planta de cable, así como las tecnologías utilizadas en una o más capas de la red. Dependiendo de su diseño, que puede ser capaces de describir completamente las conexiones en este momento o puede necesitar esperar hasta después de que la topología se aplica al diseño. Consideremos, por ejemplo, una topología de anillo. Esta topología consiste en un anillo de puntos, donde cada lugar está interconectado a dos localidades vecinas. Como se muestra en la figura 10.16, son a menudo los dos vecinos más cercanos en distancia. Cada situación implica una conexión jerárquica a otra porción de la red. Por ejemplo, si una topología de anillo se aplica a una WAN, luego cada ubicación LANWAN InterfaceInterface Frontera WAN Router

Figura 10.15 un ejemplo de lugares

Figura 10.16 una topología de anillo

Figura 10.17 una topología de anillo doble o dividida

puede ser una interfaz a una o más regional MANs o LAN conectarse este WAN. Si un anillo se aplica a una red local, esto implica un backbone de la LAN, donde cada lugar puede ser una interfaz para acceder (borde) o redes de distribución en diferentes partes de un edificio o campus. Una topología de anillo se puede modificar en una topología de doble anillo (también conocida como una topología de arillo o anillo bifurcado) mediante la adición de una conexión entre dos puntos seleccionados. Hacerlo no sólo modifica la topología, pero también cambia los patrones de flujo de tráfico de la red, agregando diversidad de ruta. Esto aumenta la importancia de los lugares seleccionados para la conexión adicional. En la figura 10.17 conexiones adicionales se agregan entre CIEFs en las regiones C y E, partir el anillo y añadir diversidad a través de la base de WAN. Otros ejemplos son la malla y las topologías de malla-parcial (una malla parcial se muestra en la figura 10.18). Como el anillo o doble anillo topologías, estas topologías también muestran lugares y su interconexión. La importancia relativa de cada ubicación en estas topologías es dependiente de los requerimientos y los flujos de tráfico de la red, los cuales se expresan en cierta medida por la elección de la tecnología utilizada para cada conexión. La importancia de los lugares en una topología de indica que puede ser sitios estratégicos en la red. Habiendo identificado estos puntos, la topología seleccionada se aplica a ellos. Desde lugares estratégicos están estrechamente acoplados a topología, normalmente todo el conjunto de puntos se utiliza cuando se aplica a la elección de la topología. Sin embargo, usted puede aplicar todo o parte de su conjunto de lugares estratégicos para la topología.

Figura 10.18 una topología de malla parcial

Una topología proporciona un comienzo hacia el desarrollo del diseño; sin embargo, no describe cada ubicación en la red. Es generalmente mejor comenzar en la parte superior de la jerarquía de la red (redes troncales de LAN o WAN) y su forma de trabajo hacia abajo. Puede aplicar una topología iterativamente, varias veces a lo largo de su red, o cambiar las topologías al moverse por la jerarquía. Aplicación de selección de tecnología En este punto debe ser capaz de aplicar sus opciones de tecnología de proceso de la arquitectura. Trata de describir completamente las tecnologías utilizadas para su red, y cómo los dispositivos estarán interconectados. En el apartado anterior hemos descrito cómo se interconectan localidades en la topología, en términos de trayectorias físicas y planta de cable. Ahora queremos aplicar opciones de tecnología a través de la topología, trabajando desde el nivel más alto de la jerarquía hasta los bordes de la red. Para nuestro backbone WAN con una topología de doble anillo, que comienzan en un lugar estratégico (probablemente uno de los lugares donde se cruzan los dos anillos), describir las opciones de tecnología dentro de ese lugar (entre los dispositivos en ese lugar), así como

tecnología elegir entre ese lugar y los otros tres que conecta con. Entonces Describimos la otra ubicación en la intersección de los anillos y luego caminar el ring, describiendo cada una de las localidades que componen los anillos. El resultado sería algo parecido a figura 10,19. Esto se puede hacer en conjunción con la aplicación de selección de equipos, discutida a continuación.

Figura 10,19 agregó una topología de doble anillo con opciones de tecnología

Aplicación de equipo de selecciones Si ha realizado su proveedores y opciones de equipamiento en este punto, usted puede aplicar al diseño. Si no, puede utilizar las opciones de tipo y clase de equipo durante el proceso de la arquitectura. Aquí se deben especificar algunos o todos de los siguientes para cada dispositivo: • Proveedor de equipo • Clase/tipo de equipo • ID de dispositivo • Tarifas y tipos de interfaz

• Configuración de dispositivos de hardware • Nivel de dispositivo OS/revisión • Grados de conexión, energía, interna (tarjeta, tablero, motor) diversidad • Cualquier información pertinente de específicos del proveedor • Protocolos de encaminamiento utilizados

Con el fin de ahorrar espacio y hacer los dibujos limpiador puede dispositivos con la misma información en las clasificaciones específicas del grupo y proporcionar la información para cada clasificación una vez en el diagrama o en un compañero diagrama o documento. Esto suma el detalle final a la descripción de sus planos. Cada ubicación en la red proporciona información de la topología, tecnología de la información y detalles sobre el equipo a colocarse en ese lugar. Esto puede tomar mucho espacio en sus planos, y puede ser en este momento que usted decide desarrollar un conjunto separado de planos que separan la red y que pueda dar más información por localidad. Figura 10.20 siguiente muestra una parte de nuestra WAN anillo con algunos datos de equipamiento añadidos.

10.5.3 Componente planes Durante el proceso de arquitectura de red se han decidido o no se va a proporcionar componentes detallados planes para funciones específicas de su red. Planes de componente se basan en información recopilada en el desarrollo de la arquitectura de red (es decir, los mecanismos de cada función, las interacciones entre estos mecanismos y las interacciones entre funciones) e incluyen diagramas para cada función. 420 Capítulo 10 diseño de redes

Figura 10.20 región C Campus con equipo información añadida

El plan de cada componente es similar a un diagrama de red o plan pero se centra en una función específica. No necesita tener un componente plan para cada función de su red, pero sólo para las funciones que desee centrarse en. Un plan común de componente se centra en la seguridad, que muestra que los mecanismos de seguridad se desplegará y donde se encuentra. Dicho plan puede incluso centrarse en mecanismos específicos. Un ejemplo de esto es que describe una arquitectura VPN como parte de un plan del componente de seguridad. Una arquitectura VPN puede ser lo suficientemente compleja como para justificar sus propios diagramas, como un subconjunto de los esquemas de seguridad general. Otro plan de componente común es para el encaminamiento y direccionamiento. Este plan componente muestra donde cada tipo de protocolo de enrutamiento de información aplicada, ruta específica, como información, y donde se producen agregación de peering y ruta. Dichos planes son especialmente útiles cuando se convirtió como superposiciones, para que puedan ver cómo cada función contribuye al diseño general. Por ejemplo, el plan de componente de seguridad puede traslaparse con los planes de enrutamiento, direccionamiento, gestión de red, rendimiento y otros, mostrando donde están ubicados e interconectados con los dispositivos de otros planes de dispositivos de seguridad. El propósito de contar con diagramas, planos y planes del componente es proporcionar a ambos un conjunto completo de datos de diseño y sistemas que se enfocan en detalles de la red. Así, aunque los planos son útiles para obtener rápidamente el panorama de la red, diagramas son útiles en la conectividad lógica de comprensión, mientras que el componente planes permiten que centrarse en el enrutamiento, seguridad y otras funciones de red. Además, tener juegos adicionales de diagramas y planes realmente puede simplificar sus puntos de vista de la red. Planos de la red pueden convertirse en difícil de manejar, información tanta en los dibujos que llegan a ser difíciles de leer, entender y utilizar, especialmente cuando se trata interacciones rastro entre varios dispositivos, mientras que los diagramas y planes del componente del embalaje adaptado a las interacciones de seguimiento. Planos y planes componente deben ser complementarios. Cuando se desarrollan planos y planes del componente, el proyecto de red describe infraestructura física, incluyendo la planta de cable, seguridad física y HVAC; mientras que los planes componente proporcionan detalle en cada una de las funciones de red. Por lo general, enrutamiento, conmutación y abordar están incluidos en el plan de acción, así como en un plan del componente, como son las funciones más básicas de la red. Es útil tener planes componente desarrollados como superposiciones, donde puede colocar uno Diagrama encima de otro, para ver cómo y dónde se aplican las funciones dentro de la red, y donde se solapan (Figura 10.21). Como tal,

Figura 10,21 componente Plan recubrimientos línea en lugares estratégicos

422 Capítulo 10 diseño de redes

necesitan línea de estructuralmente, para que cada ubicación en la red se muestra en el mismo lugar en el plan de cada componente. Sin embargo, en el desarrollo de su diseño de red puede decidir tener el tradicional conjunto de planos que describe todos los aspectos de su diseño. Para redes de pequeña escala puede ser capaz de describir toda la información pertinente en un solo plano o conjunto de planos. Si elige hacerlo, información de esta sección en desarrollo planes de componente simplemente se aplicaría al desarrollo de un conjunto de planos.

10.6 Trazabilidad de diseño Cada decisión tomada con respecto a su diseño de red debe ser trazable a una o más decisiones de arquitectura y así requisitos y declaraciones de problema. Esto completa la trazabilidad de sus decisiones, una parte crítica de análisis, arquitectura y procesos de diseño. La capacidad de rastrear cada decisión de diseño la forma de cómo aborda la arquitectura del proyecto, requisitos, y declaraciones de problema es una capacidad de gran alcance. Figura 10.22 ilustra esta trazabilidad. Cada decisión de diseño se asigna a una o más decisiones de arquitectura,

que luego a los requisitos, que a las declaraciones de problema. Esto le permite demostrar cómo cada decisión de diseño enfrenta los problemas y requerimientos de su proyecto. Sin trazabilidad que no sepa que algunos de los problemas y requerimientos de su proyecto no se están cumpliendo, que hay decisiones de arquitectura y diseño que no abordan los requerimientos del proyecto, o que su diseño puede ser fuertemente cargada hacia el particular necesidades y problemas. Trazabilidad muestra así su diseño de red direcciones de requerimientos del proyecto y las declaraciones de problema. Se muestra un ejemplo de trazabilidad en la figura 10.23. Este ejemplo es para que un proyecto definir e implementar un perímetro de seguridad de la red como parte de una estrategia de defensa en profundidad. Las decisiones de diseño sobre proveedores y selecciones de equipos y desarrollo de normas, seguimiento a las decisiones de arquitectura cada uno direcciones que se asignan a sus respectivos requisitos, y finalmente a la declaración del problema. Con esta técnica se puede ver claramente cómo aplicarán las decisiones tomadas durante el análisis, arquitectura y diseño de procesos para resolver los problemas establecidos del proyecto. He encontrado trazabilidad útil en una variedad de situaciones, los descritos aquí incluyendo.

Figura 10.22 diseño decisiones seguimiento a las decisiones de arquitectura, requisitos y declaración de problema

Figura 10.23 un ejemplo de trazabilidad para un proyecto de perímetro de seguridad de red

Trazabilidad de diseño

Afrontar para el diseño de la red. Para una variedad de razones alguien puede desafiar todo o parte de su diseño de red. Estos retos pueden ser razonable y esperado, como cuando se agregan nuevos ingenieros de red al equipo de diseño, o cuando los ingenieros fuera el proyecto ver el diseño por primera vez. Con este proceso de este tipo de desafíos debe ser raro, sin embargo, como red de ingenieros dentro de su organización deben tener temprano y frecuente acceso a la información del proyecto como evoluciona a través de análisis, arquitectura y procesos de diseño. A veces estos desafíos pueden ser más políticos que técnico. Se trata de un lamentable aspecto de los proyectos, que debemos estar preparados para la dirección. Afortunadamente, habrá una gran cantidad de información en el momento de que llegar al diseño, que puede utilizarse para abordar los desafíos, independientemente de si son realmente técnico o simplemente de carácter político. Antes de aplicar la disciplina en este libro, mis experiencias eran a menudo que diseños de red Haz desafiados tarde en el proceso de diseño, a veces en competencia por el financiamiento, otras veces sobre diferentes opiniones en cuanto a opciones de diseño. Cuando se hicieron tales desafíos, inevitablemente siguió largos períodos de discusión, discusiones, discusiones sobre diseños que compiten. Lo que descubrí fue que, sin un sistema bien documentado del problema declaraciones, requerimientos, decisiones de arquitectura y diseño, era difícil enfrentar decisiones de diseño que compiten (tecnologías, proveedores, equipo). Argumentos a menudo vinieron a las diferencias de opciones personales o deseos, o a veces simplemente lo sentía mas cómoda, no una posición particularmente fuerte desde el que impulsar un proyecto hasta su conclusión. Sin embargo, después de aplicar el análisis, arquitectura y procesos de diseño, mis experiencias han sido sorprendentemente (o tal vez no tan sorprendentemente) constantes. Armado con declaraciones de problema bien documentado, los requerimientos y decisiones de arquitectura y

diseño, han sido (y siguen siendo) constantemente capaces de enfrentar desafíos todos mis proyectos. De hecho, cuando se presenta este tipo de desafíos, todos los argumentos rápidamente secaran tan pronto como describo la trazabilidad de las decisiones a sus requerimientos y declaraciones de problema. Como se verá por sí mismo, esto es un testamento a la energía de este proceso. Presupuesto de direccionamiento, horario y de recursos. Otro tipo de desafío para el diseño de red es justificar su presupuesto, agenda y gastos de recursos. Preguntas como "¿por qué estamos gastando X$ para este proyecto?," "lo que estamos recibiendo por este dinero?," "¿por qué llevará este proyecto tan largo para terminar?" puede que deba abordarse. Además, puede que necesite solicitar más tiempo o financiamiento para completar su proyecto y tendrá que hacer lo necesario 426 CHAPTER 10 Network Design

argumentos. La información de fondo proporcionada por los procesos en este libro puede ser muy útil para discutir su caso. Poner al día sobre cómo evolucionó el diseño de los recién llegados. La documentación que se han desarrollado durante todo el proyecto puede ser muy útil en ayudar a otros a seguir la evolución de su diseño. Por ejemplo, he encontrado que ésos desconocedores con el diseño (por ejemplo, recién contratado ingenieros) a menudo tienen preguntas acerca de por qué y cómo se toman decisiones particulares. Tener que explicar el diseño a tal gente puede evitarse proporcionando la documentación del proyecto. En este sentido, puede ser útil para desarrollar una carpeta de proyecto que contiene el pertinente análisis, arquitectura, y diseño de información. Mantener disponible la documentación adecuada es útil, no sólo para los recién llegados hasta la fecha, sino también para llevar a reuniones y discusiones, cuando usted podría ser llamados a proporcionar tal información. Puede describir trazabilidad textualmente o a través de diagramas o con una combinación de estos. Prefiero utilizar diagramas, porque hacen más fácil ver las conexiones entre problema declaraciones, requerimientos, decisiones de arquitectura y las decisiones de diseño. Sin embargo, también utilizo texto (hojas de cálculo) para describir la trazabilidad, generalmente como parte de la documentación que entregue como productos del proyecto. Desde la perspectiva del diseñador, mostrando cómo diseño decisiones seguimiento a las decisiones de arquitectura provee dos comprobaciones de cordura importante. En primer lugar, si tienes las decisiones de diseño que no se asignan a las decisiones de arquitectura (y así no se asignan a los requisitos o declaraciones de problema), entonces sus decisiones de diseño no son apropiados para el proyecto o el conjunto de decisiones de arquitectura no es completa. En segundo lugar, si la correlación entre las decisiones de diseño y decisiones de arquitectura es cargada pesadamente hacia algunas decisiones de arquitectura, entonces esas decisiones de arquitectura pueden ser demasiado amplias en alcance. Mientras que el segundo caso no es tan crítico como la primera, todavía puede indicar la necesidad de un reexamen de las decisiones de arquitectura. En la figura 10.24 hay decisiones de diseño que no se asignan a las decisiones de arquitectura y así no se asignan a los requisitos o declaraciones de problema. Esto demuestra que estas decisiones de diseño (números 2, 6, 7 y 14) son importantes para el proyecto, pero faltan las decisiones de

arquitectura apropiada (posiblemente requisitos y declaraciones del problema); o que estas decisiones de diseño no son importantes para nuestro proyecto. Con trazabilidad puede ver claramente cuando esto ocurre. Sin ella, usted podría terminar con las decisiones de diseño que son inadecuado y costoso para su proyecto. En la misma figura también tenemos el problema contrario: hay una decisión de arquitectura que no las decisiones de diseño a él (número 5). Esto demuestra Trazabilidad de diseño

Decisiones

ya sea que no hemos hecho un trabajo completo de desarrollo de nuestras decisiones de diseño, por lo que hay que abordar la arquitectura de decisión 5; o que esta decisión de arquitectura no es importante para nuestro proyecto. Si no es importante, se debe retirar y su asignación a los requisitos examinados. En la figura 10.25 tenemos una asignación completa entre las decisiones de arquitectura y diseño; sin embargo, la asignación está fuertemente sesgada hacia algunas decisiones de arquitectura (números 1 y 2). Esto no puede ser un problema; de hecho, puede demostrar que estas decisiones son más importantes que los demás. El desarrollo del problema declaraciones y requisitos puede incluso han indicado que estas decisiones de arquitectura más importantes sería que los otros. Sin embargo, también puede indicar que estas decisiones de arquitectura son demasiado amplias, que podrían ser separados en más enfocado a las decisiones. Cuando ves tal sesgo en trazabilidad, indica que usted debe examinar sus decisiones de arquitectura para asegurarse de que son lo que realmente quieres.

428 CHAPTER 10 Network Design

Figura 10.25 trazabilidad muestra mapeo pesadamente entre decisiones de arquitectura y diseño Sesgado hacia las decisiones de arquitectura 1 y 2

10.7 Métricas de diseño Recordemos que una parte necesaria de cada requisito validado es que tienen uno o más indicadores asociados a él, y que estas métricas se utilizan para determinar su éxito en el cumplimiento de cada requisito. Métricas de acoplamiento a las necesidades de la red es un compromiso importante que hacen para asegurar el éxito del proyecto. Las métricas asociadas con los requisitos deben acoplarse también a métricas que han desarrollado para el diseño. Como indicadores asociados con los requisitos, métricas de diseño describen cómo mides el éxito de sus decisiones de diseño. Ejemplos comunes de parámetros de diseño incluyen la capacidad de alcanzar un nivel deseado de la diversidad en la red, a través de enrutamiento topología, redundancia de equipos, redundancia de servicios y similares, a menudo asociado con métricas para requerimientos de performance como red la disponibilidad y fiabilidad o requisitos de entrega de servicio como SLAs; la capacidad de retardo extremo a extremo o ida y vuelta de obligado en la red, a menudo en apoyo de aplicaciones en tiempo real o interactivas, otra vez asociada con métricas de performance y servicio Conclusiones

requisitos de entrega; o la capacidad para ofrecer capacidad deseada o niveles de rendimiento (ya sea a través de la red o para aplicaciones específicas y los aparatos), también asociada con métricas de rendimiento y requerimientos de entrega de servicio. Como era de esperar, un componente adicional de trazabilidad es la capacidad de métricas de seguimiento desde el diseño a sus necesidades. Es deseable hacer esto siempre que sea posible, ya que proporciona evidencia directa para satisfacer los requerimientos con el diseño entregado. En los ejemplos anteriores, donde los parámetros de diseño son requisitos asociados con (y así trazable a) métricas, demostrando el funcionamiento y prestación de servicios en la red cumple con métricas de requisitos y diseño de métricas. En este diseño de sentido métricas sirven para validar su diseño. 10,26 de la figura muestra un ejemplo de esto. Utilizando la matriz de trazabilidad de perímetro de seguridad mostrada anteriormente, se proporciona una métrica para el requisito 3: demostrar que el perímetro de seguridad puede ser cerrado abajo en X segundos, donde X debe ser determinado. Esta métrica es apoyada por dos de las decisiones de arquitectura, para desarrollar estándares para componentes de red perimetral y seguridad y para proporcionar un control centralizado de DMZs, agregando el tiempo de cierre (X) como uno de los estándares a desarrollar y por hacer X uno de los criterios por el cual se evaluarán proveedores y productos. Decisiones de diseño sobre proveedores-proveedor de servicios y evaluaciones están influenciadas por X, que se determina durante el desarrollo de normas. Parámetro para el diseño 4 de decisión es el desarrollo exitoso de X, que puede utilizarse con éxito demostrar cierre abajo del perímetro dentro de X segundos, y satisfacer los parámetros de la decisión de diseño 3 y 3 requisito. Tenga en cuenta que el valor de X es fundamental para el diseño de la red y el éxito del perímetro resultante. Treinta minutos y treinta segundos para X hace la diferencia entre tener un perímetro completamente automatizado y ser capaces de tener los seres humanos en el lazo. También puede hacer la diferencia en el mantenimiento de un ataque de seguridad de llegar más allá de su perímetro.

10.8 Conclusions El diseño de la red es el producto final del análisis, arquitectura y procesos de diseño. El diseño es donde tus decisiones arquitectónicas con respecto a la topología de red y tecnologías junto con selecciones de equipo, vendedores y proveedores de servicios para proporcionar diagramas detallados planos y planes del componente de la red.

Figura 10,26 métricas para el diseño pueden ser juntados con métricas para los requisitos de

Ejercicios

Mediante el uso de los procesos descritos en este capítulo, así como a lo largo de este libro, usted podrá desarrollar mejores diseños de la red.

10.9 Exercises 1. ¿Cuáles son las decisiones de diseño ad hoc? ¿Cómo reduzco la calidad del diseño resultante de tales decisiones? Dar un ejemplo de una decisión ad hoc diseño. 2. Si hemos seguido los procesos de análisis y arquitectura, ¿qué productos de los procesos se utilizan como entrada para el diseño? 3. ¿Cuáles son las principales diferencias entre el primer orden, segundo orden y productos de diseño de thirdorder? 4. ¿Qué son los planos de red, diagramas de red y planes componente? ¿Por qué tendría un diseño de red conjuntos de cada uno de ellos? 5. ¿Cuáles son los principales componentes del proceso evaluación de proveedores, prestadores de servicios y equipo? 6. En la evaluación de proveedores, prestadores de servicios o equipos para un diseño de red, ¿por qué sería la semilla el proceso de evaluación? 7. Cuál de los siguientes criterios de evaluación más probable es que se aplican a las evaluaciones de equipo, cuáles se aplican a las evaluaciones del proveedor de servicios, y que se aplican a ambos? • Disponibles acuerdos de nivel de servicio (SLAs)

• Cumplimiento de los estándares (IETF) • Tiempo medio entre fallos (MTBF) • Tiempo promedio entre la interrupción del servicio (MTBSO) • Escalabilidad de hardware

8. En la matriz de evaluación en la figura 10.10, cómo las calificaciones habría cambiado si: a. Los pesos relativos se cambiaron para ser 1 (es decir, no hubo pesos relativos)? b. Los tres últimos criterios (servicios, operaciones, escalabilidad) cada uno dieron un peso de 1.0, mientras que los demás se mantuvo sin cambios? c. Cada peso relativo se multiplicó por 10 (es decir, los cambios a escala de 0 – 1 0 – 10)? 9. Los resultados de una evaluación de proveedor de servicios son los siguientes: servicio proveedor A: 28,7 puntos; Proveedor B: de servicios 28,5 puntos; Servicio proveedor C: 29.0 puntos; Servicio proveedor D: 27.5 puntos; Servicio proveedor E: 21,9 puntos; Servicio proveedor F: 27,6 puntos. ¿Cómo modificaría este conjunto de servicios candidatos?

Esta página dejada intencionadamente en blanco

Glosario de términos

regla del 80/20 Una regla por la que el 80% del tráfico de una red es local y 20% es remoto. Capacidad de adaptación Necesita un requisito de usuario para el sistema sea capaz de adaptarse a los cambios de los usuarios. Dirección Por IP, un número de 32 bits que identifica un dispositivo en la capa de red. Hacer frente a Aplicación de identificadores (direcciones) a los dispositivos en varias capas de protocolo (por ejemplo, enlace de datos y red). Máscara de dirección Por IP, un número de 32 bits que identifica qué bits de la dirección se consideran parte de la red y (por defecto) que bits se consideran parte de la. Prefijo de la dirección Cuando una máscara de dirección destaca por su longitud N en pedacitos, como / N

Hacer frente a Asignar identificadores locales o globales, privadas o públicas, temporales o persistente a los dispositivos de. Accesibilidad Un requisito de usuario por lo que los usuarios o gestión puede permitirse comprar por la red. Alarma A eventos de gestión de red que activa una notificación en tiempo real al personal de la red. Véase también evento. Requisitos de la aplicación Requisitos que se determinan a partir de la información, experiencia o prueba y lo que se necesitan aplicaciones para operar con éxito en el sistema. Componentes de la arquitectura Estas son las áreas funcionales de la red, cuyas relaciones definen la arquitectura de red. Ejemplos de componentes de la arquitectura IP servicios, seguridad y privacidad, gestión de red, direccionamiento y enrutamiento. Áreas Segmentos de un diseño de red que son el resultado del dimensionamiento de la red. Aplicaciones asíncronas Aplicaciones que son relativamente insensibles a tiempo, ya sea no asumiendo ninguna relación de tiempo entre origen y destino, o que la relación de sincronización es fuera de los límites de la sesión aplicaciones.

433

Pista de auditoría El conjunto de decisiones para la arquitectura y el diseño, datos y documentos. Sistema autónomo (AS) Una colección de redes bajo el control de mismo. Disponibilidad de La relación entre la frecuencia de fallos críticos y el momento de restaurar el servicio. Esto es también conocido como disponibilidad operativa. Ancho de banda La capacidad teórica de uno o más elementos de la red en el sistema. Ancho de banda ∗ producto de la demora Una estimación de la cantidad máxima de información que puede ser en tránsito a través de una tecnología particular en un momento dado. Servicio best-effort Servicio de red en la que no hay ningún control sobre cómo la red va a satisfacer la solicitud de servicio y existen garantías asociados a este servicio. Servicio será impredecible y poco fiable,

con un rendimiento variable en un rango de valores (de la red siendo de carácter [rendimiento 0] para el mínimo común denominador del rendimiento a través de todas las tecnologías en la ruta de extremo a extremo). BGPv4 Un protocolo de pasarela externo basado en vector path. Bloqueo Cuando dispositivos detener sus cómputos, a la espera de información de otros dispositivos informáticos. Dominio de broadcast Un grupo de dispositivos direccionables de red donde todos los dispositivos en ese grupo se pueden llegar por una dirección de red, la dirección de difusión. Difusión de tecnologías Tecnologías que apoyan la capacidad de un dispositivo de comunicarse simultáneamente con todos los otros dispositivos en su red o subred, mediante el uso de una dirección de difusión conocida específica a la tecnología de red de la red. Control de admisión de llamadas Un mecanismo para limitar el número de llamadas en una red y así controlar la asignación de recursos. Capacidad Una medida de la capacidad del sistema para transferir información (voz, datos, video, combinaciones de éstos). Plan de capacidad Una descripción por escrito de rendimiento de la red (capacidad) para los flujos que se describen en el flowspec. Planificación de la capacidad Ancho de banda de ingeniería sobre en la red para dar cabida a la mayoría a corto y largo plazo tráfico fluctuaciones. También conocida como ingeniería del tráfico. Gestión centralizada Cuando todos los datos de gestión (por ejemplo, ping, sondeos SNMP / respuestas, traceroutes) irradian desde un único sistema de gestión (normalmente grande). Caracterizar el comportamiento Que representa cómo los usuarios y las aplicaciones utilizan la red para desarrollar y comprender sus necesidades. Controles y equilibrios Métodos para duplicar las mediciones para verificar y validar datos de gestión de la red. Bloque CIDR Un grupo de direcciones de red que están representados por un anuncio de encaminamiento entre dominios sin clase (CIDR) de la forma (dirección de red, máscara de longitud). Direccionamiento Classful Longitudes de máscara de aplicación predeterminado a direcciones para apoyar una gama de tamaños de red. El resultado es un conjunto de clases de direcciones (A, B, C, D y E), cada uno de ellos soporta un tamaño de red máximo diferentes. Clasificación La capacidad para identificar el tráfico fluye como parte del acondicionamiento del tráfico. Classless interdomain routing La ausencia de límites de clase en enrutamiento de red. Modelo de arquitectura cliente – servidor Un modelo de arquitectura que sigue el modelo de flujo de cliente – servidor. En este caso hay localizaciones obvias para elementos arquitectónicos, en particular donde se combinan flujos. Modelo de flujo de cliente – servidor Un modelo de flujo en el que los flujos son asimétricos y jerárquico enfocado hacia el cliente. Juntada de cerca En el computación distribuida flujo modelo, cuando hay frecuentes transferencias de información entre dispositivos informáticos.

Granularidad gruesa En el computación distribuida flujo modelo, cuando cada tarea está dedicado a un solo dispositivo informático. Características del componente Las características entre los componentes de la arquitectura (servicios IP, administración de redes, seguridad y privacidad y direccionamiento y enrutamiento) que describen las relaciones entre estos componentes. Estas características son funcionamiento, interacciones, dependencias, compensaciones y restricciones de. Restricciones de componente Restricciones dentro de una arquitectura de componentes o entre las arquitecturas de componente; incluso puede ser a través de la arquitectura entera (referencia). Dependencias de componentes Requisitos que un componente tiene en uno o más componentes para que funcione. Interacciones de los componentes Los requisitos que cada componente tiene que comunicarse con otros componentes. Operación del componente Determinar los mecanismos que conforman cada componente, el funcionamiento de cada mecanismo y funcionamiento de ese componente en su conjunto. Componente las compensaciones Decisión de puntos en el desarrollo de una arquitectura para priorizar y elegir entre las características y funciones de cada componente y por tanto optimización la arquitectura general (referencia). Flujo compuesto Una combinación de requisitos de múltiples aplicaciones, o de las corrientes individuales, que comparten un enlace común, ruta o red. Confianza Una medida de la capacidad de la red para ofrecer los datos sin errores o pérdida en el rendimiento de diseño. Configuración Para la gestión de la red, la configuración de parámetros en un elemento de red para la operación y el control de ese elemento. Conforme tráfico El tráfico que está dentro de límites de rendimiento determinado por medición (acondicionamiento del tráfico). Soporte de conexión Cuando se establece una conexión con la tecnología cuando se transfiere información a través de la red. Red de distribución de contenido Una red que pasa por alto el núcleo de la Internet para proporcionar mejor rendimiento en la entrega de información a sus usuarios. Corrientes críticas Flujos que se consideran más importante que otros en que son superiores en rendimiento, tienen requisitos estrictos, o servir a los más importantes usuarios, aplicaciones y dispositivos.

Flujos de datos Ver Flujos de. Fregadero de datos Un dispositivo que recoge o termina los datos en una red. Origen de datos Un dispositivo que produce datos sobre una red. Estándar de facto Una norma generalmente aceptada por ser ampliamente implementado y utilizado. Por defecto la ruta La ruta usada cuando no hay ninguna otra ruta para ese destino. Es la ruta de último recurso. Propagación de ruta por defecto La técnica utilizada para informar a la red o subredes o áreas funcionales de la ruta por defecto.

Retardo de Una medida de la diferencia de tiempo en la transmisión de información a través del sistema. Servicios diferenciados Un mecanismo de calidad de servicio que define un conjunto de valores (puntos de código de servicios diferenciados denominada [DSCP]) para las clases de tráfico fluye para ser utilizado por los mecanismos de control de recursos. Direccionalidad La preferencia de un flujo que más requisitos en una dirección que en otra. Modelo de arquitectura de computación distribuida Un modelo arquitectónico que sigue el-computación distribuida flujo modelo y en el cual los datos fuentes y fregaderos son lugares obvio para arquitectura. Modelo de flujo de computación distribuida Un modelo de flujo que tiene la inversa de las características del modelo de flujo de cliente – servidor o es un híbrido de peer-to-peer y cliente – servidor flujo modelos. Gestión distribuida Cuando hay múltiples componentes separados para el sistema de gestión y estos componentes se colocan estratégicamente en toda la red, localizar el tráfico de gestión de red y la distribución de dominios de administración. Aguas abajo Tráfico que fluye en la dirección de la fuente al destino. Que cae En tráfico acondicionado, descartando tráfico. Cifrado de Un mecanismo de seguridad que cifrado algoritmos se aplican junto con una clave secreta para cifrar datos para que sean ilegibles si interceptada. Modelo arquitectónico de extremo a extremo Modelo arquitectónico que se centra en todos los componentes en el camino de extremo a extremo de un flujo de tráfico. Características de extremo a extremo (elemento de red) Las características que se pueden medir a través de múltiples elementos de red en la ruta de acceso de uno o más flujos de tráfico y pueden extenderse en toda la red o entre dispositivos. Umbrales específicos de medio ambiente Umbrales de performance que están determinados por el medio ambiente de la red actual del proyecto en el que está trabajando. Evento Algo que ocurre en la red que es digna de destacar, ya sea informativo, como un problema, o como una alarma. Protocolos de portal exterior Protocolos de enrutamiento que comunicarán información de enrutamiento (accesibilidad y métricas) sobre todo entre culo. Interfaces externas Las interfaces de red entre su red y otra, fuera (externas) redes. Características Funciones de red y el rendimiento que se desea pero que no son necesarios para la red con éxito ayuda a sus usuarios, aplicaciones y dispositivos de. Granularidad fina En el computación distribuida flujo modelo, en la que una tarea se divide entre varios dispositivos y la computación se realiza al mismo tiempo. Cortafuegos Combinaciones de uno o más mecanismos de seguridad, implementados en los dispositivos o elementos de red (routers), que se colocan en lugares estratégicos dentro de una red. Análisis de flujo El proceso de caracterización de tráfico fluye por una red, donde es probables que ocurra, y qué niveles de rendimiento requieren de. Flujos de Sistemas de tráfico de red (aplicación, protocolo e información de control) que tienen algunos atributos comunes, tales como dirección de origen/destino, tipo de información, enrutamiento u otra

información end-to-end. Los flujos también tienen direccionalidad. También conocido como flujos de tráfico o flujos de datos. Basada en el flujo de modelos arquitectónicos Modelos que aprovechan los flujos de tráfico de la especificación de flujo particular. Modelos de flujo Grupos de flujos que exhiben características de comportamiento específicas y consistentes. Modelos de flujo se caracterizan principalmente por su direccionalidad, la jerarquía y la interconectividad. Priorización del flujo Ranking de flujos basado en su importancia (por ejemplo, número o los usuarios, aplicaciones o dispositivos compatibles). Especificación del flujo A lista de los flujos para una red, junto con sus requisitos de desempeño y niveles de prioridad (si existe). También conocido como un flowspec. FLOWSPEC Ver Flujo especificación. FLOWSPEC algoritmo Un mecanismo para combinar los requisitos de funcionamiento (capacidad, retardo y confiabilidad) para flujos de tal manera que describe el rendimiento compuesto óptimo para ese flujo o grupo de flujos de. Función Una gran capacidad de una red. Modelos arquitectónicos funcionales Modelos que se centran en una o más funciones o características previstas en la red. Áreas funcionales Grupos dentro del sistema que comparten una función similar. Pueden ser grupos de usuarios (grupos de trabajo), aplicaciones, dispositivos o combinaciones de éstos, y pueden compartir tareas de puestos de trabajo similares, ubicaciones físicas o funciones dentro de la red (por ejemplo, enrutamiento de columna vertebral). Acceso general Común acceso de usuarios a aplicaciones de computación y recursos de almacenamiento de información a través de una red. Red de rendimiento general Una red que no tiene un distintivo conjunto de aplicaciones, usuarios o hosts que serían el controlador de rendimiento para esa red. Umbrales de general Los umbrales de rendimiento que se aplican a la mayoría o todas las redes. Dispositivos informáticos genéricos Computadoras de escritorio y portátiles comunes que tienen la mayoría de los usuarios. Servicio garantizado Servicio predecible y fiable a tal grado que, cuando el servicio no está disponible, el sistema es en alguna manera responsables de la red. Límite duro Un límite de enrutamiento que protocolos de Gateway Exterior se utilizan predominante para pasar información de enrutamiento. Estado duro Determinación y persistente mantiene información de conexión a lo largo de la ruta de acceso de una conexión entre origen y destino. Modelo de arquitectura cliente – servidor jerárquico Un modelo de arquitectura basado en el modelo de flujo jerárquico de cliente – servidor. Además de las funciones, características y servicios están enfocados en ubicaciones de servidor y cliente – servidor de flujos, también se centran en los flujos de servidor –. Modelo de flujo jerárquico de cliente – servidor Un modelo de flujo que tiene las características de un modelo de flujo de cliente – servidor pero que también tiene varias capas o niveles, de entre los servidores.

Gestión jerárquica Cuando las funciones de administración (monitoreo, visualización, almacenamiento y procesamiento) se separan y se colocan en dispositivos separados. Jerarquía El grado de concentración de redes o tráfico fluye en puntos de interconexión en la red, así como el número de niveles de puntos de interconexión en la red. Alto rendimiento Un indicador de que la solicitud de servicio o las características de rendimiento de requisito están mayores que un umbral de rendimiento determinado para esa red. Red de alto rendimiento Una red que por lo general tiene uno o algunos aplicaciones, grupos de usuarios o dispositivos cuyos requisitos de desempeño son significativamente mayores que otros requisitos de rendimiento para esa red. Modelo arquitectónico de alto rendimiento/general-rendimiento Modelo que se centra en la identificación de redes o partes de una red como funcionamiento general, como alto rendimiento o como componentes de ambos. Tiempo de respuesta humana Una estimación del umbral de tiempo cuando los usuarios comienzan a percibir el retraso en el sistema. Administración en banda Cuando los flujos de datos para la gestión de la red siguen los mismos caminos de la red como el tráfico fluye para sus aplicaciones y los usuarios. Flujo individual El flujo asociado con una sola sesión de una aplicación de. Condiciones iniciales Inicial de entrada para el proceso de análisis de requisitos, que consiste en el tipo de proyecto de red, ámbito de la arquitectura y diseño, diseño de arquitectura inicial metas y cualquier fuerza exterior actuando sobre la red. Instrumentación Para administración de red, el conjunto de herramientas y utilidades necesarias para monitorear y probe la red para la gestión de datos. Mecanismos de interconexión Mecanismos que interconectan tecnologías de red, incluyendo compartieron medios de comunicación, cambio, puente y encaminamiento. Servicios integrados Un mecanismo de calidad de servicio que define valores y mecanismos de asignación de recursos a los flujos a través de la ruta de extremo a extremo del flujo de. Aplicaciones interactivas Aplicaciones que asuman alguna relación de tiempo entre origen y destino, mientras que la sesión de aplicación está activa, sin embargo, la relación de sincronización no es tan estricta como lo es en tiempo real. Interactivo a granel aplicaciones Aplicaciones en las que los retrasos de red end-to-end o ida y vuelta no son el retraso predominante para esa aplicación, pero el procesamiento en el componente de dispositivo o aplicación es el retraso predominante. Interactive explotar aplicaciones Aplicaciones en las que los retrasos de red end-to-end o ida y vuelta son el retraso predominante para esa aplicación. Interactividad Un requisito de usuario por un tiempo de respuesta desde el sistema (como la red) que es del orden de los tiempos de respuesta de los usuarios. Interconectividad Un equilibrio a la jerarquía en una red, interconectividad es el grado de conexiones dentro de la red a distintos niveles en el diseño, para ofrecer un mayor rendimiento a través de la red. Protocolos de Gateway interior (IGP) Protocolos de enrutamiento que comunicarán información de enrutamiento sobre todo dentro de un as

Intranet/extranet modelo arquitectónico Modelo arquitectónico que se centra en la seguridad y la privacidad, incluyendo la separación de los usuarios, dispositivos y aplicaciones basados en el acceso seguro. IPSec Un protocolo para proporcionar autenticación y cifrado entre dispositivos en la capa de red. Servicios IP Un conjunto de mecanismos para configurar, operar, administrar, disposición y cuenta de recursos en la red que asignan el rendimiento a los usuarios, aplicaciones y dispositivos de. Latencia de El sistema o tiempo de respuesta del componente, una medida del retardo que incorpora el dispositivo y el proceso de aplicación, teniendo en cuenta el tiempo para completar una tarea. Límite Un límite entre conformes y no conformes regiones; se toma como un límite superior o inferior para una característica de funcionamiento de. Combinados libremente En el computación distribuida flujo modelo, cuando puede haber poco o ninguna transferencia de información entre los dispositivos de informáticas. Bajo rendimiento Un indicador de que la solicitud de servicio o las características de rendimiento de requisito son inferiores a un umbral de rendimiento determinado para esa red. Capacidad de mantenimiento Una medida estadística del tiempo para restaurar el sistema a estado operacional después de que ha experimentado una falla de. De la marca Etiquetar un paquete IP con un nivel de prioridad, como parte del acondicionamiento del tráfico. Mecanismos de Hardware y software que ayudan a una red para lograr la función de cada uno. Metadatos de Tipos de información adicional sobre los datos recogidos, como referencias a los datos, fecha y hora de cuándo fueron generados los datos y cualquier indicación que estos datos de referencia a otros datos. Medición de la Medición de las características de un flujo de tráfico, rendimiento temporal como parte del acondicionamiento del tráfico. Selección de MIB Determinar que MIB SNMP de utilizar y aplicar, así como que las variables en cada MIB son apropiadas, para la red. Aplicaciones de misión crítica Aplicaciones que requieren confiabilidad predecible o alta. Monitoreo Obtención de valores para end-to-end, por enlace y por elemento características de gestión de red. Flowspec varias partes Una especificación de flujo que describe los flujos que han garantizado requisitos; pueden incluir flujos que tienen requisitos estocásticos o de mejor esfuerzo. Mascarilla natural Máscara de dirección IP que coincide con un límite de clase. Traducción de direcciones de red La asignación de direcciones IP de un reino a otro. Esto suele ser entre público y privado espacio. Análisis de red Estudio de componentes de red, sus entradas y salidas, para comprender el comportamiento de la red en situaciones variables. Arquitectura de red Desarrollar una alto nivel estructura end to end de la red. Esto incluye las relaciones entre los componentes principales de la arquitectura de la red, como seguridad, gestión de red, direccionamiento y enrutamiento de.

Diseño de redes Detalles (físicamente) la arquitectura de red de referencia, evaluación y elección de tecnologías para cada área de la red, así como estrategias para conectar estas tecnologías en toda la red. Elemento de red Un componente individual de la red que participa en uno o más de las capas de protocolo. Entorno de red Todo lo que es externo a la red, tales como los entornos físicos o de negocios. También puede incluir usuarios, aplicaciones y dispositivos, aunque se consideran generalmente con la red para ser parte del sistema. Administración de redes Proporcionar funciones de control, planificar, asignar, implementar, coordinar y controlar recursos de la red. Seguridad de red perimetral Las interfaces externas entre su red y redes externas de protección. Retardo de propagación de la red Una estimación del tiempo que tarda una señal a un medio físico o un enlace. Privacidad de la red Un subconjunto de seguridad de la red, centrándose en la protección de redes y sus servicios de acceso no autorizado o la divulgación de. Requisitos de la red Solicitudes de capacidades en la red, generalmente en términos de rendimiento y función, que son necesarias para el éxito de esta red. Seguridad de la red La protección de redes y sus servicios de acceso no autorizado, modificación, destrucción o divulgación. Ofrece garantía de que la red realiza correctamente sus funciones críticas y de que no hay efectos secundarios dañinos. Servicios de red Niveles de rendimiento y función en la red. Tecnologías de acceso múltiple de no-broadcast Red de tecnologías que no intrínsecamente se difundir apoyo. Véase también difusión tecnologías. Tráfico de disconformes El tráfico que está fuera de límites de funcionamiento, según lo determinado por la medición (acondicionamiento del tráfico). Aplicaciones de tiempo real no Aplicaciones con diferentes end-to-end retrasar los requisitos, a veces más estrictas (en términos de la cantidad de retardo) de aplicaciones en tiempo real, pero el destino se espera (dentro de razón) hasta que se reciba la información. Interfaz hacia el norte A la interfaz de administración que está orientada hacia funciones de administración (así hacia arriba o hacia el norte) de más alto nivel. Este término es comúnmente utilizado para la interfaz de administración de redes de servicio o gestión empresarial. Una parte flowspec Una especificación de flujo que describe los flujos que tienen solamente requisitos de mejor esfuerzo. También conocido como un flowspec unitario. Conveniencia operativa Una medida de cómo nuestro diseño de red puede configurar, supervisar y ajustado por los operadores del cliente. OSPF Un IGP basado en un algoritmo de estado de enlace. Gestión fuera de banda Cuando se proporcionan diferentes caminos para flujos de datos de gestión de red y flujos de tráfico de usuario. Filtrado de paquetes Un mecanismo de elementos de red explícitamente negar o pasar los paquetes en puntos estratégicos dentro de la red. Compañeros Usuarios, aplicaciones, dispositivos, redes o culo que actúan en el mismo nivel de su jerarquía. Por ejemplo, en un modelo jerárquico de cliente – servidor, servidores que actúan en el mismo

nivel (por ejemplo, directamente sobre sus clientes) se consideran pares. Culo que forman un acuerdo de peering (usando BGP4 y políticas) se consideran compañeros. Modelo arquitectónico de igual a igual Basado en el modelo de flujo de peer-to-peer, las características importantes de este modelo son que no hay obvio ubicaciones de elementos arquitectónicos, funciones, prestaciones y servicios hacia el borde de la red, cerca de los usuarios y sus dispositivos; y los flujos de son end-to-end entre los usuarios y sus equipos. Modelo de flujo de igual a igual Un modelo de flujo en el que los usuarios y aplicaciones son bastante constantes a lo largo de la red en su comportamiento de flujo. Rendimiento El conjunto de niveles de capacidad, retardo y confiabilidad en una red. Características (elemento de red) por enlace y por elemento Características que son específicas del tipo de elemento o conexión entre elementos monitoreados. Seguridad física La protección de dispositivos de acceso físico, daños y hurto. Jerarquía de planificación Integrar los métodos de diseño de red para aislar y ocultar su tráfico de uno a otro y las redes. Políticas de (1) sistemas (formales o informales) de declaraciones de alto nivel sobre cómo deben asignarse entre los usuarios de recursos de la red. (2) alto nivel declaraciones sobre las relaciones entre redes o culo, como con acuerdos de peering. Una política puede tener una acción (por ejemplo, soltar, aceptar, modificar) el tráfico que coincide con uno o más parámetros (por ejemplo, número o lista de números y métricas). De la interrogación Sondeo activamente la red y elementos de red para gestión de datos. Intervalo de sondeo Período de tiempo entre encuestas. Véase también votación. Almacenamiento de información primario Ubicaciones de almacenamiento donde se organizaron los datos para períodos cortos (por ejemplo, horarios). Privacidad Un requisito para proteger la santidad de usuario, aplicación, dispositivo e información de la red. Direcciones IP privadas Las direcciones IP que no pueden ser anunciadas y transmitidas por elementos de la red y los dispositivos en el dominio público (es decir, Internet). Direcciones IP públicas Direcciones IP que pueden ser anunciadas y transmitidas por elementos de la red y los dispositivos en el dominio público (es decir, Internet). Infraestructura de clave pública A infraestructura de seguridad que combina mecanismos de seguridad, políticas y directivas en un sistema que está dirigido para el uso a través de redes públicas sin garantía (por ejemplo, Internet), donde la información está cifrada mediante el uso de un público y un privado par de claves criptográficas es obtenido y compartido a través de una autoridad de confianza. Calidad En análisis de requerimientos, se refiere a la exigencia del consumidor por la calidad de la presentación al usuario. Calidad de servicio También conocido como QoS, determinar, establecer y actuar en niveles de prioridad para los flujos de tráfico. Aplicaciones críticas para el tipo de Aplicaciones que requieren una predecible, delimitado, o alto grado de capacidad de. Análisis en tiempo real Ajuste y monitoreo de umbrales o límites para las características de end-to-end, por enlace o por el elemento a corto plazo o inmediata notificación de eventos y transitorios.

Aplicaciones en tiempo real Aplicaciones que tienen una relación de estricta sincronización entre origen y destino, con uno o más contadores de tiempo fijado para la recepción de información en el destino. Arquitectura de red de referencia Una descripción de la arquitectura completa, considerando todos sus componentes. Es una recopilación de las relaciones desarrolladas durante el proceso de arquitectura de la red. Fiabilidad (1) un indicador estadístico de la frecuencia de falla de la red y sus componentes y representa las paradas no programadas del servicio. (2) en análisis de requerimientos, fiabilidad es un requisito de usuario por servicio siempre disponible. Acceso remoto Basado en tradicional dial-en las sesiones de punto a punto y las conexiones de red privada virtual de acceso a la red. Requisitos Descripciones de funciones de red y el rendimiento necesarios para la red con éxito ayuda a sus usuarios, aplicaciones y dispositivos de. Análisis de requerimientos Reunir y derivados requisitos para entender comportamientos del sistema y la red. Mapa de necesidades Un diagrama que muestra las dependencias entre aplicaciones y dispositivos, que se utilizará para el análisis de flujo de ubicación. Especificación de requisitos Un documento que enumera y da prioridad a los requerimientos se reunieron para su arquitectura y diseño. Control de recursos Mecanismos que asignar, controlar y gestionar recursos para el tráfico de la red. RIP y RIPv2 IGP que se basa en un algoritmo de enrutamiento vector distancia. Agregación de ruta La técnica intercambio de información de enrutamiento entre culo, generalmente entre los proveedores de servicios de redes de tránsito y entre redes de cliente grande. Filtro de ruta Una declaración, configurada en uno o más routers, que identifica uno o más parámetros IP (por ejemplo, un origen o destino dirección IP) y una acción (p. ej., gota o adelante) cuando el tráfico coincide con estos parámetros. Filtrado de ruta La técnica de aplicación de filtros para ocultar redes del resto de un AS o para agregar, borrar o modificar las rutas en la tabla de enrutamiento. Enrutamiento de De aprendizaje acerca de la conectividad entre redes y aplicar esta información de la conectividad para reenviar los paquetes IP hacia su destino. Límites de distribución Separaciones físicas o lógicas de una red basan en requisitos o administración de esta red. Flujos de distribución Flujos de información de enrutamiento, pasado entre áreas funcionales y entre culo. Programación Determinar el orden en que tráfico se procesa para la transmisión sobre una red. Almacenamiento de información secundario Sitios de almacenamiento esos datos gestión agregada de múltiples sitios de almacenamiento de información primario. Garantizar la biblioteca de sockets Un mecanismo de seguridad que utiliza autenticación de RSA para reconocer la identidad digital y RC4 para cifrar y descifrar la transacción o comunicación el acompañamiento de una parte. Seguridad Un requisito para garantizar la integridad (exactitud y autenticidad) de la información y recursos físicos de un usuario, así como acceso a los recursos del usuario y del sistema.

Conciencia en seguridad Recibiendo los usuarios educados y participan con el día a día aspectos de la seguridad en su red y ayudar a entiendan los riesgos potenciales de violación de las políticas de seguridad y procedimientos. Célula de seguridad En la arquitectura de red, cuando la seguridad limita el rendimiento para operar dentro de un perímetro de seguridad, o celular. Procedimientos y políticas de seguridad Declaraciones formales sobre las normas de información, red y sistema de acceso y uso diseñado para minimizar la exposición a las amenazas de seguridad. Servidor Dispositivo de computación que brinda un servicio a uno o más usuarios (es decir, clientes). Servicio Ver Servicio de red. Características del servicio Rendimiento de red y parámetros funcionales que se utilizan para describir servicios. Niveles de servicio Un grupo o conjunto de características que conforman una representación de alto nivel de servicios. Métricas de servicio Mediciones de características de servicio en la red para supervisar, verificar y gestionar servicios. Acuerdo de nivel de servicio También conocido como un SLA, un contrato formal o informal entre un proveedor y un usuario que define los términos de la responsabilidad del proveedor para el usuario y el tipo y grado de rendición de cuentas si son de esas responsabilidades no admita Oferta de servicio Servicios ofrecidos por la red para el resto del sistema. Plan de servicio Una descripción por escrito del rendimiento de la red (capacidad, retardo y confiabilidad) requerido para los flujos que se describen en el flowspec. Solicitud de servicio Servicios que son solicitados por los usuarios, aplicaciones o dispositivos de red. Modelo de proveedor de servicios de arquitectura Modelo arquitectónico basado en las funciones de proveedor de servicios, centrándose en la privacidad y seguridad, prestación de servicios a los clientes (usuarios) y facturación. Servicio de conmutación Conmutación basada en información de flujo o end-to-end, depende del tipo de servicio requerido. Período de sesiones Una instancia de una o más aplicaciones simultáneas, dando lugar a uno o más flujos de tráfico. Que forma En tráfico acondicionado, retrasando el tráfico para cambiar una característica de funcionamiento de. Mecanismo de medio compartido Cuando todos los dispositivos en la red (o subred) comparten el mismo medio físico. Límite suave Un límite de enrutamiento que IGPs predominante se utilizan para pasar información de enrutamiento. Estado blando Determinar y mantener el estado hasta que se establece la conexión o durante un corto período después de que la conexión se establece. Especializada de dispositivos Dispositivos que proporcionan funciones específicas a sus usuarios. Específicos Según lo utilizado con seguridad, se refiere a normas bien definidas acerca de quién, qué y dónde se aplica seguridad.

Estado Información (direcciones típicamente locales o end-to-end) asociados con las conexiones en una tecnología. Stateful Determinar y mantener información de estado para las conexiones entre origen y destino. Apátrida No determinar o mantener cualquier información de estado entre fuente y destino para las conexiones de. Rutas estáticas Las rutas que se configuran manualmente, por personal de red o scripts, en elementos de la red y que no cambian hasta que manualmente eliminado o modificado. Servicio estocástico Servicio que requiere cierto grado de previsibilidad (probabilidad), más de lo posible, sin embargo no requiere de la responsabilidad de un servicio garantizado. Almacenamiento de los archivos Sitios de almacenamiento secundario y terciario para datos de gestión de red. Red de trozo Una red con una única trayectoria dentro o fuera de lo Subred Un segmento de una red, creada como un nivel adicional de jerarquía impuesta en una red, a través de cambiar su máscara dirección. Máscara de subred Una máscara de dirección que se ha cambiado de su máscara natural (clase) para agregar un nivel adicional de jerarquía. Subredes Parte de usar el dispositivo (host) del espacio de direcciones para crear otra capa de jerarquía. Esto se hace cambiando la máscara de dirección. Máscara de Supernet La máscara de dirección creada cuando supernetting — es decir, reducir el tamaño de la máscara para direcciones de red agregadas. Supernetting Agregación de direcciones de red al cambiar la máscara de dirección para disminuir el número de bits asignados a la red. Capacidad de soporte Una medida de qué tan bien el cliente puede hacer la ejecución del sistema, diseñado, durante toda la vida del sistema. De la conmutación Información (por ejemplo, las células, Marcos, paquetes) entre segmentos de una red o subred. Esto se hace generalmente en las capas de enlace o red pero puede ocurrir en cualquier nivel. Sistema de Un conjunto de componentes que trabajan juntos para apoyar o proveer conectividad, comunicaciones y servicios a los usuarios del sistema. Arquitectura de sistemas Desarrollar una alto nivel estructura end-to-end para el sistema, que consiste en usuarios, aplicaciones, dispositivos y redes. Esto incluye las relaciones entre cada uno de estos componentes. Metodología de sistemas Ver la red que son arquitectura y diseño, junto con un subconjunto de su entorno (todo lo que la red interactúa con o impactos,) como un sistema de. Tele ∗ servicios El conjunto de aplicaciones multimedia, como teleseminarios, telelearning, teleconferencia y así sucesivamente. Almacenamiento terciario Sitios de almacenamiento de información donde la gestión de datos es seguros y persistentes (permanente o semipermanente). Análisis de amenazas Un proceso utilizado para determinar qué componentes del sistema necesitan ser protegidos y los tipos de riesgos para la seguridad de que deben ser protegidos.

Umbral de Un valor para una característica de rendimiento que es una frontera entre dos regiones de conformidad y, cuando se cruzaron en una o ambas direcciones, va a generar una acción. Rendimiento de procesamiento La capacidad de realización del sistema o sus elementos de red. Modelos topológicos Modelos basado en un arreglo topológico o geográfico, a menudo utilizado como puntos de partida en el desarrollo de la arquitectura de red. Ingeniería de tráfico Ancho de banda de ingeniería sobre en la red para dar cabida a la mayoría a corto y largo plazo tráfico fluctuaciones. También conocido como planificación de la capacidad. Flujos de tráfico Ver Flujos de. Transitorios de Eventos de corta duración o cambios en el comportamiento de la red. Trampa de A umbral configurable por el usuario para un parámetro. Utilizados en la gestión de la red. Análisis de tendencias Con datos de gestión de red para determinar comportamientos de red a largo plazo, o las tendencias de. Oportunidad Un requisito de usuario para poder acceder, transferir o modificar la información dentro de un marco de tiempo tolerable. El hacer un túnel Encapsular información en encabezados de protocolo con el fin de aislar y proteger esa información. Dos partes flowspec Una especificación de flujo que describe los flujos que tienen requerimientos de estocásticos y pueden incluir flujos que tienen requerimientos de esfuerzo. Flowspec unitario Una especificación de flujo que describe los flujos que tienen solamente requisitos de mejor esfuerzo. También conocido como un flowspec uno. Aguas arriba Tráfico que fluye en la dirección del lugar de destino a la fuente. Necesidades de los usuarios El conjunto de requisitos se reunieron o derivado por el usuario, lo que se necesita por los usuarios para llevar a cabo con éxito sus tareas en el sistema. Subnetting de longitud variable Subredes en que subred múltiples se utilizan máscaras, creando subredes de diferentes tamaños. Redes privadas virtuales Aplicación de túnel para crear múltiples redes aisladas a través de una infraestructura común. Grupos de trabajo Grupos de usuarios que tienen lugares comunes, las aplicaciones y requisitos o que pertenecen a la misma organización. xDSL Opciones de una variedad de DSL, como asimétrica DSL simétrico DSL, DSL de alta velocidad y DSL ISDN.

Esta página dejada intencionadamente en blanco

Glosario de siglas

ABR

autenticación, autorización, contabilidad y asignación tasa de bits disponible

ACL

lista de control de acceso

AF

reenvío asegurado

AH

encabezado de autenticación

API DE

interfaz de programación de aplicaciones

AR

Informe de aceptación

ARCP

copia remota asincrónica

ARP

Protocolo de resolución de direcciones

COMO

sistema autónomo

AAAA

CAJEROS modo de transferencia asíncrono AUTOMÁTICOS Átomo Monitoreo de cajeros automáticos SER

mejor esfuerzo

BER

tasa de error de bit

BGPv4

Versión de Border Gateway Protocol 4

BSD

Berkeley Software Distribution

AUTOBUSES

servidor de difusión/multidifusión

CA

autoridad de certificación

CAC

control de admisión de llamadas

CAD

asistido por computadora dibujo asistido por ordenador/diseño Cipher block encadenamiento

CBC CBQ 451

colas basadas en clases

CBR CD

tasa de bits constante disco compacto

CDN

red de distribución de contenido

CDR

revisión crítica de diseño

CF

flujo compuesto

CHAP CIDR

Protocolo de autenticación de desafío y respuesta encaminamiento entre dominios sin clase

CIR

tasa de información comprometida

CLI

interfaz de línea de comandos

CLR

proporción de pérdida de células

CMIP

Protocolo de información de gestión común

CMOT

CMIP sobre TCP/IP

CMR

proporción de células misinsertion

POLICÍAS

servicios comunes de la política abierta

CORBA CoS

arquitectura de intermediario de petición de objeto común clase de servicio

CUNAS

comercial fuera de la plataforma

CPU

unidad central de procesamiento

CRM

gestión de relaciones con clientes

CT

tomografía computada

DES

estándar de cifrado de datos

DET

determinista

DHCP DiffServ

Protocolo de configuración dinámica de Host servicios diferenciados

DMZ

zona desmilitarizada

DNS

sistema de nombres de dominio

DR.

Ruta por defecto

DSCP DSL

punto de código de servicios diferenciados bucle de abonado digital

DSx

digital de señal (x =1, 3)

ESD dWDM

unidad de servicio de datos multiplexación por división de longitud de onda densa

EBGP

BGP externo

ECS

servidor de cálculo ingeniería

EF

reenvío acelerado

EGP

Exterior Gateway Protocol

EMS

sistema de gestión de elemento

ENET

Ethernet

EDC

capacidad operacional extendida

ERP

Planificación de recursos empresariales

ESP

seguridad encapsuladora

f

flujo

FA

área funcional

FAA

Administración Federal de aviación

FB

límite de flujo

FCAPS FCIP

fallas, configuración, contabilidad, desempeño y seguridad Fibre channel sobre IP

FDDI

interfaz de datos distribuida de fibra

FE

Fast Ethernet

FIFO

primero en la primera salida

FMECA

modos de falla, efectos y análisis de criticidad

FTE FTP

equivalente/tiempo completo empleado de tiempo completo Protocolo de transferencia de archivos

FY

año fiscal

GB/s GigE

gigabits por segundo Gigabit Ethernet

HDLC

control de enlace de datos de alto nivel

HiPPI

interfaz paralela de alto rendimiento

HMAC

código de autenticación de mensaje de función hash tiempo de respuesta humana

TERAPIA DE REEMPLAZO HORMONAL HTTP

Protocolo de transferencia de hipertexto

HVAC

calefacción, vacío, aire acondicionado

HW o H/W

hardware

IBGP

BGP interno

ICD

Descripción de control de interfaz

ICMP ID

Protocolo de mensajes de Control Internet identificador de

IETF

Internet Engineering Task Force

iFCP

Protocolo canal de fibra de Internet

IGP

Protocolo de Gateway interior

Ilán

aislamiento LAN

INTD

retraso de la interacción

IntServ

servicios integrados

ENTRADASALIDA

entrada/salida

COI

capacidad operativa inicial

IP

Protocolo de Internet

IPSec

Seguridad IP

ISP

Proveedor de servicios Internet

SE

tecnología de la información

IXC

interexchange carrier

KB/s KB/s

kilobits por segundo kilobytes por segundo

L

enlace

L2F

reenvío de capa 2

L2TP

2 protocolo de túnel de capa

LAN

red de área local

LANE

Emulación de LAN

LDAP

Protocolo de acceso a directorio ligeros Cliente de emulación de LAN

LEC

LES

Servidor de conexión de emulación de LAN Servidor de emulación de LAN

LIS

subred IP lógica

LLNL LOH

Laboratorio Nacional de Lawrence Livermore arriba de la línea

LRU

unidad de reparación local

HOMBRE

red de área metropolitana

MB/s

megabits por segundo

MB/s

megabytes por segundo

MC

misión crítica

MD

Resumen de mensaje

MDR

tarifa de datos mínima

MFTP

múltiples del FTP

MIB

base de información de gestión

MIS

sistemas de información gerencial

MPC

Cliente MPOA

MPS

Servidor MPOA

MPLS

conmutación por etiquetas multiprotocolo

LECS

MPOA RESONANCIA MAGNÉTICA MS

multiprotocolo sobre ATM la proyección de imagen de resonancia magnética milisegundos

TIEMPO MEDIO tiempo medio entre fallas ENTRE FALLOS MTBCF tiempo medio entre fallos críticos tiempo promedio entre la interrupción del servicio TIEMPO MEDIO tiempo medio para reparar DE REPARACIÓN NA o N/A no disponible MTBSO

SIESTA

punto de acceso de red

NAPT

traducción de puerto de direcciones de red

NAS

servidor de acceso de red

NAT

traducción de direcciones de red

NBMA

acceso múltiple de no difusión

NFS

servidor de archivos de red

NHRP

Next-Hop Resolution Protocol

NIC

tarjeta de interfaz de red

NM

Administración de redes

NMS

sistema de gestión de red

NOC

Centro de operaciones de red

NOS

sistema operativo de red

Nº

requisito de la red

OAM OAM & P

operaciones, administración y mantenimiento OAM y la provisión

OCx

portador óptico (x =1, 3, 12, 24, 48, 192)

OLTP ORR

procesamiento de transacciones en línea Informe operacional

OS

Sistema operativo

OSI

Protocolo de enrutamiento de primera de camino más corto abierto interconexión de sistemas abiertos

OSS

sistema de soporte de operaciones

P

peering

PADI

Iniciación de PPPoE active discovery

OSPF

PADO

Oferta de PPPoE active discovery

PADRI

PC

Solicitud de descubrimiento activo de PPPoE Sesión de descubrimiento activo de PPPoE Protocolo de autenticación de contraseña ordenador personal

PDA

Asistente personal digital

PDP

punto de decisión política

PDR PEP

tasa de datos máxima; revisión de diseño preliminar punto de aplicación de la política

PING

Internet groper de paquete

PKI

infraestructura de clave pública

PM

Programa de gestión

POH

arriba del camino

PoP

punto de presencia

PoS

paquete sobre SONET; punto de venta

COJINES PAP

MACETAS DE servicio telefónico llano viejo PP

panel de parcheo

PPP

Protocolo punto a punto

PPPoE

PPP sobre Ethernet

PPTP

Protocolo de túnel punto a punto

Por

calidad de servicio

R&D RA

investigación y desarrollo agregación de ruta

RADIO RBD

servicio de acceso remoto dial-en usuario diagrama de bloques de confiabilidad

RC

tasa crítica

ROJO

al azar detectar temprano

RF

filtro de ruta

RFC

solicitud de comentarios

RFI

solicitud de información

RFP

solicitud de propuesta

SOLICITUD solicitud de presupuesto DE COTIZACIÓN

RMON

Protocolo de información de enrutamiento confiabilidad, mantenibilidad y disponibilidad Monitoreo remoto

RO

de sólo lectura

RPV

vehículo pilotado remotamente

RSA

Rivest-Shamir-Adleman

RSVP

Protocolo de reserva de recursos

RT

tiempo real

RW

lectura y escritura

s

segundos

SA

Administrador de sistemas

SAN

red de área de almacenamiento

SAR

segmentación y reensamblaje

SCM

cadena de suministros

SCSI

interfaz estándar de equipos pequeños

SDR

tasa de datos constante

RIP RMA

SHA SIP

algoritmo hash seguro Protocolo de inicio de sesión

SLA

acuerdo de nivel de servicio

SLAPM

Métricas de rendimiento de SLA

SMDS

conectar el servicio de datos multimegabit

SMON

interruptor de control

SMS SNMP

servidor multicast especial, sistema de gestión de abonado Simple Network Management Protocol

SOH

arriba de la sección

SONET

red óptica síncrona

SPE

Envolvente de carga útil SONET

SSH

shell seguro

SSL

Biblioteca de sockets seguros

ST

estocástico

SW o S/W

software

TCP

Protocolo de Control de transmisión

T&I

prueba e integración

TFTP

Trivial File Transfer Protocol

ToS

tipo de servicio

UBR

tasa de bits no especificada

INTERFAZ DE USUARIO UID

interfaz de usuario

UPS

fuente de alimentación ininterrumpida

USM

modelo de seguridad basado en el usuario

VBR

tasa de bits variable

VLAN

LAN virtual

ID de usuario

VoIP

máscara de subred de longitud variable voz sobre IP

VPN

red privada virtual

VRML

Lenguaje de marcado de realidad virtual red de área amplia

VLSM

WAN

WFQ

multiplexación por división de longitud de onda weighted fair queuing

WG

Grupo de trabajo

WRED

weighted random detectar temprano

xSP

proveedor de servicios (varios)

WDM

Esta página dejada intencionadamente en blanco

Índice Números de página seguidos por "f" denotan figuras

A AAAA, 374 Listas de control de acceso, 366 Modelo de arquitectura de base de distribución de acceso, 233f, 233, 234, 239, 241, 341f, 352, 377 Regiones de acceso, de red, 219 Adaptabilidad, 65 Dirección de adición de 264 en el bloque CIDR, clase 267, 257 – 258

Clase B, 257 – 258 clase C, 257, 258, 264 clase cálculos y, 252 Clase D, clase E, definición 258 258 de formato 251 de 251 global, 252, 253, 254f ilustración de, capa de enlace de 251f, local 253, 252, 254f persistente, 253, IP privada 254f, 251, 253, 254f, 268 IP pública, 251, 253, 254f temporal, 253, 254f Enlaces de dirección, 269 A. Véase también Fondo de enrutamiento, classful 250, 251, 257-259 enrutamiento entre dominios sin clases, plan de componente 267, 420 definición de 250

462 Descripción de, 220, 222, 229 dinámica, 221, 253, 293 relaciones externas, 292 – 293 jerarquía en interacciones 258 – 259, 232 relaciones internas, mecanismos de 291 – 292, 257 – 269 gestión de redes y, 230, 292, 327 rendimiento y, 230, 292, 354 privado, 268 – 269 escala de 278 seguridad y 230, 292, 380 – 381 estrategias para subredes 278 – 280 Descripción de, 259 – 261-de longitud variable, 221, 262-264, 279, 280f supernetting, 264 Descripción de la máscara de dirección de 251 natural, modificación de superredes de 257-258 265F Dirección prefijo, 267, 268f Control de la admisión, 344 asequibilidad, 65 – 66 Aplicaciones asíncronas, 71 a granel transporte de datos, 74 – 75 cliente – servidor, comando y control 75, 73 – 74 índices de datos de, 131-computación distribuida, 74 enfocando, para identificar y desarrollar flujos, 169 – 172 interactivo, 67, 71, 72, 72f lugares de misión crítica 75 – 76, 67 – 68 no en tiempo real, 71 operaciones, administración, mantenimiento y provisioning, 75 tasa crítica, 67 – 69 en tiempo real, 67, 70-71 seguridad, 369-371 telemetría, 73 – 74 Tele * servicio top 75 N visualización de 173 – 174, 74 Desarrollo Web, acceso y uso, 74 Comportamiento de la aplicación, 116-117 Grupos de aplicaciones, 73-75 Mapa de la aplicación, 76f Capacidad de requisitos de uso. Ver Capacidad de definición 146 – 147, demora 66. Ver Retrasar confiabilidad. Ver Modelos arquitectónicos de fiabilidad Acceso/distribución / Núcleo, 233f, 233 – 234, 239-241, 341f, 352, 377 aplicación de 242 – 244 Descripción de 232 end-to-end, 238, 238f flujo. Ver Modelos funcionales, 237 – 238 intranet/extranet, 237, 237f de flujo LAN/MAN/WAN, 232 – 233, 233F, multi-con gradas, 239 238-proveedor de servicios, solo-con gradas de 237, 238 modelos topológicos, uso 232 – 234, 238244 Componente de arquitectura. Ver Arquitectura de componentes red. Ver Arquitectura de red referencia. Ver Arquitectura de referencia sistemas, 244-245 Aplicaciones asíncronas, 71 Audit trail, 23 – 24. Automático de la conmutación, 118 Sistemas autónomos, 17, 270, 271, 274, 286

Análisis de la disponibilidad de 118 – 119 definición de, 49, 50, 68, 118 ecuación de 118 medidas de tiempo de inactividad, 119 – 120 tasa de error, la tasa de pérdida 125, uptime 125. Ver Tiempo de actividad B Ancho de banda, 4 – 5 Aplicación del comportamiento, 116 – 117 caracterizar, usuario 113 – 117, 115 – 116 Capacidad de esfuerzo, 195 Servicio de mejor esfuerzo, 39 – 40 Ofertas de servicio de mejor esfuerzo, 43 Flujo bidireccional, 163, 164f Modelos planes de componente y, 421 definición de 390 desarrollo de, selecciones de equipo 409, 419 puntos estratégicos, selecciones de tecnología 411-414, 417 selección de topología, 414, 417, 416f, 418f Versión de protocolo de gateway de frontera 4, 283, 286, 287, 289 Enrutadores de borde, de 286 Puente, 250 A granel aplicaciones, 71 – 72, 72f Transporte de datos a granel aplicaciones, 74 – 75 Explosión de aplicaciones, 71 – 72, 72f gestión, 300 C Control de admisión de llamadas, 41 Capacidad inicial operativa, 88 Requisitos de capacidad de uso, 68–69 esfuerzo, definición 195, 47 Descripción de 40 requisitos, métricas de servicio 130 – 133 para 110 Plan/planificación de capacidad, 4, 197 Interruptores de clase portadora, 388 Instalaciones de exchange independiente del portador, 386-387 Procedimientos de urgencias, 141 Células, 225, 355 Administración centralizada, 315, 326 Autoridades de certificación, 372 Caracterizar el comportamiento de la aplicación de comportamiento, 116 – 117 modelado y simulación, 113 – 114 Comportamiento de los usuarios, 115 – 116 Controles y equilibrios, 319 CIDR. Ver Classless interdomain routing CIEF. Ver Servicios de intercambio independiente del portador Dirección de clase A, 257 – 258 dirección de clase B, 257 – 258 Basada en la clase cola, 348 Dirección de clase C, 257, 258, 264 Dirección de clase D, 258 Dirección de clase E, 258 Classful abordar, 221, 257, 259 267, enrutamiento entre dominios sin clase Aplicaciones cliente – servidor, 75 Flujo de cliente – servidor modelos arquitectónicos de, 235, carácter asimétrico 235f Descripción 183 de 183 de modelo de flujo – computación distribuida vs 190 ejemplos de, 184, 185 f jerárquicos arquitectónicos de,

235, 236f description of, 185–188 esquema de aplicaciones Web de 184f, 184 Aplicaciones de comando y control, 73 – 74 Tipos de información, 35 Administración común Protocolo de información, 111, 303–304 Arquitecturas componente direccionamiento/enrutamiento. Ver Abordar; Enrutamiento de las interacciones de componentes, 216 – 217 restricciones 215 – 216, 218 definición de, 212, 213, 215 dependencias, 215, 217 – 218 desarrollo de, 216, 218 funciones Descripción de, 215, 218 priorización de 228 entrada para el desarrollo, las relaciones internas 218, 215 – 216, 219, 220f, 228

Arquitecturas de componentes ( Continuó ) mecanismos, 215 – 216, 217f, 219 dirección de la red. Ver Optimización de gestión de red de, rendimiento 226. Ver Arquitectura de rendimiento modelo de proceso de 227f relaciones entre 227 enrutamiento. Ver Routing seguridad. Ver Resumen de seguridad de compensaciones 246, 215, 217 Plan de componente, 391, 419-422 Flujo del compuesto, 165f, 165 – 166 Cluster de computación, 189f Descripción de dispositivos informáticos, 77 – 78 de los flujos de entre, 197 – 198 alto rendimiento, 197 – 198 Confianza, 88, 134, 143, 145 Configuración, 310-311 Conforme el tráfico, 345 Bitstream del parámetro obligado, Descripción de las limitaciones 133, 215, 216, 218 de gestión de redes, 326 Redes de distribución de contenido, 17, 186 Convergencia veces Descripción de 281 para abrir ruta más corta primero, 284–285 Regiones centrales, de red, 219, 240 Requisitos fundamentales, 58 – 59 Descripción de flujos críticos de 166 – 167 jerárquica cliente – servidor modelo de flujo, 186 Criticidad, 117 Expectativas del cliente, 104 D Recopilación de datos de metadatos de 304 – 305, 321 administración de redes, 319-322 procesamiento de, 305 copiado selectivo de, 321, 321f almacenamiento de 320 proveedores, equipos de proveedor, y proveedor de servicios, 399–401 Flujos de datos. Ver De flujo Migración de datos, 198, 321 Tarifa de datos, 130 – 133 Unidades de servicio de datos, 39

Datos de los fregaderos y fuentes de cliente – servidor como 183 definición, ejemplos de 175, 175-179, 176f Transferencia de datos, 132 Descifrado, estándar De facto de 371 – 373, 39 Ruta predeterminada, 273 Propagación de ruta por defecto, 221, 273 Retrasar la definición de, 48, 64, 69-to-end, 69, 128-130 general umbrales, 126 – 127 respuesta humana tiempo interacción 126, 126 límites, propagación de red 126 – 127, 126 – 127 requisitos, 125 – 130 ida y vuelta, 69, 128-130 servicio métricas para 110 umbrales de, 126, 127, 129 tipos de, 69, 72f Variación del retardo, 130 Zona desmilitarizada, 271-272 Descripción de las dependencias de, 215, 217 – 218 administración de redes, 324–325 Diseño arquitectura y comparaciones entre 387f 213-215, Fondo de, planos de 3 – 6, 390 problemas presupuestarios, 425-426 diseño y construcción, comparación entre 389 – 390 desafíos, 425 plan componente, 391, 419 – 422 conceptos asociados 386-394 limitaciones, 102 de toma de decisiones con respecto a, 23, defensibility 385 de, definición de 22 a 24 de 214 Descripción de 385 desarrollo, 135 del proceso de evaluación utilizado en, producto de primer orden 9, 388 goles de, 101 entradas, 8f, 393 métricas, 393, 428-429 modelo para diseño de la red de 2427. Ver Conveniencia operacional diseño afectado por, 134 – 136 salidas, costos postimplementation 8f, 52 – 53 proceso de, 394-395 productos de, 390-393 propósito de 8 configuración para, producto de segundo orden 4, 388, 388f productos de tercer orden, 388-389 trazabilidad definición de 393 para educar nuevos empleados acerca de la evolución del diseño, 426 – 427 ejemplos de indicaciones de 423f – 424f, 425 – 427 métricas alinean con requisitos, 429 proveedor, equipo de proveedores, y proveedor de servicios de evaluaciones, 398-399, 405–407 refinamiento de los criterios, datos 401 – 403, 399 – 401 Descripción de, 392-393, 395 – 397 orden de priorización 407, 403-405 ratings, 401-405 siembra el proceso de evaluación, 397-398 Resumen calificaciones, 405 Dirección de destino, para paquetes, 254–255 Características de dispositivos de, 302 – 303 componentes de 80f informática, 77 – 78 definición de, 302 localidades de características de rendimiento 81 – 83 80 – 81 cola de, 347-348 especializado, 78 – 79, 79f Diagramas de lógicas, 408, 409f – 410f de bloque de confiabilidad, 138, 139f Puntos de código de servicios diferenciados, 339 DiffServ, 338-342 Direccionalidad, de modelos de flujo, 180 Algoritmo de enrutamiento de vector distancia, 284 Aplicaciones de computación distribuida, 74 Modelo de flujo – computación distribuida aplicación de 243 características arquitectónicas, 236, 236f Descripción de, 188-191

Gestión distribuida, 316, 326 Redes distribuidas, 281 Regiones de distribución, de red, 219 Conceptualización de la diversidad de Descripción 16f de, 15, 118 enrutamiento protocolo y 281 DMZ. Ver Zona desmilitarizada Soporte de la documentación afectada por, 140 técnicos, 140 – 141 Tiempo de inactividad definición de cantidad tolerable 119 de 120 Caída del tráfico, 345-346 Topología de doble anillo, 416f, 416–417, 418f Dinámica dirección, 221, 253, 293 Protocolo de configuración dinámica de host, 253 E máscara de subred de 8 bits, 263 Gestión de elemento, 301 Cifrado, 226, 371-373 Modelo de arquitectura end-to-end, 238, 238f Características de extremo a extremo, 302–303 Retardo de end-to-end, 69, 128-130 Prueba del sistema de extremo a extremo, 138 Requerimientos de las empresas, 90 Umbrales específicos de medio ambiente, 117, 145-147 Tasa de error, 125, 143-144 Evento, 306 Notificación de eventos control de, 86, 306–307 Existen redes de restricciones, 101, 103 requisitos, 84 – 85 Exterior gateway protocolos frontera puerta de enlace del Protocolo de versión 4, 283, 286, 287, 289 Descripción de 271, 284 protocolo de información de enrutamiento 21, 282, 284 Protocolo de gateway de frontera exterior, 286 Extranet, 375 F Administración de fallas, 312 Características, 59 Requisitos financieros, 89-90 Firewalls, 374 Primero en la primer a cola, 347 Flow(s) entre dispositivos informáticos, 197 – 198 bidireccional, 163, 164f clasificación de 165f compuesto, 344, 165 – 166 crítica

Descripción de 166 – 167 para el modelo de flujo jerárquico de cliente – servidor, 186 datos fuentes y sumideros, definición de 175-180 de 162 aguas abajo, 166 estimado, identificación de 226 y desarrollo de centrarse en una aplicación, 169 – 172 Resumen de, 167 – 168 desarrollo de perfil utilizado, 172 – 173 diagrama esquemático de, top 168f N aplicaciones usadas individual de 173 – 174, 164 Flow(s) (continuación) medición de Perfil de desempeño de 344 – 345 de Descripción del desarrollo de 166 de 172-173 requisitos de funcionamiento para, priorización de 204f de, 191-193, 342-344 propósito de enrutamiento de 163. Ver Enrutamiento de flujos unidireccionales, 163, 164f, 166 Flujo punto de agregación, 171-172, 172f Definición de análisis de aplicación de ejemplo 161, del flujo 197-205 importancia de propósito 163 de 206 Resumen de, 205-206 Características del flujo, 163 Flujo de mapa, 202, 203, 242, 243 Flow mapping, 169, 170f Modelos de flujo cliente – servidor. Ver Cliente – servidor modelos de flujo definición de direccionalidad 180 de 180 computación distribuida – aplicación de, 243 características arquitectónicas, 236, 236f Descripción de, 188-191 ejemplo de, 201, 202f peer-to-peer, 181-183, 234 – 235, 235f esquema de 239f FLOWSPEC algoritmo, 195 – 196 Descripción de, 193, 194, 194 varias partes, 196 1 parte, 194, 195f dos partes, 194, 195f, 205f Flujo especificación. Ver FLOWSPEC FMECA, 139, 139f máscara de subred de 4 bits, 262-263 Áreas funcionales, 269, 270f, 289 Funcionalidad, 66 Requisitos fundamentales, 58 G Recopilación de la descripción de requisitos de las condiciones iniciales 100, 100-104 Acceso general, 30 Definición de límites generales de 117 por retraso, 126 – 127 de uptime, 120, 121, 124 Genéricos de informática dispositivos, 77 – 78 Dirección global, 252, 253, 254f Garantía Descripción del funcionamiento de requisitos 148, 149, 196 Servicio, 39 – 40, 44 H Descripción de límites duros de ruta 271 filtración utilizado en 273 Modelo de flujo jerárquico de cliente – servidor características arquitectónicas de, 235, 236f Descripción de, 185-188 Gestión jerárquica, 316-317, 326

Jerarquía en abordar, 258 – 259 Descripción de 14 – 15, 16f gestión de red, protocolo de enrutamiento 301f y 281 subredes, 260261 Dispositivos informáticos de alto rendimiento, 197 – 198 Requerimientos de servicio de alto rendimiento, 42 Puntos calientes, 18 Tiempo de respuesta humana, 126 Me Paquetes ICMP, 144 Administración, 312-313, en banda 325 En banda camino, 86 Flujo individual, 164 Decisión informada, 228 Capacidad de infraestructura, planificación, 18–19 Condiciones iniciales, 100-104, 151, 152f Capacidad operativa inicial, 88, 135 Instrumentación, 308-310 Retraso de la interacción, 126 Bulto de aplicaciones interactivas, 71 – 72, 72f, explosión 127, 71 – 72, 72f, 127 Descripción de, 67, 71 y 72 Interactividad, 64 – 65 Protocolos de gateway interior Descripción de, 21, 271 abrir ruta más corta primero. Ver Abrir ruta más corta primero Protocolo de gateway fronterizo interno, 286 Internet Engineering Task Force, 31, 60 Intranet/extranet modelo arquitectónico, 237, 237f IntServ, 339, 340f Dirección IP de, 251, 253, 254f calidad de servicio, 338-342 IPSec, 369 Aislamiento LAN, 271-272 J Jitter, 48, 228 L LAN Descripción del aislamiento 83, 271 – 272 tráfico escala, 318 modelo arquitectónico de LAN/MAN/WAN, 232 – 233, 233f, 239 Tiempo de respuesta de latencia, 48 Planos de disposición utilizan pulg. Ver Descripción de planos de diagramas lógicos de 395, 407, 408, 408, 409f – 410f Retardo de límites, y específicas del entorno 126 – 127, 145 – 147 de servicio, 45 Dirección de capa de enlace, 253 Algoritmo de enrutamiento de Link-state, 284 Dirección local, 252, 254f Red de área Local. Ver LAN Dependiente de la ubicación de dispositivos especializados, 79 Diagramas de lógicas, 408, 409f – 410f Tasa de pérdida, 125, 144

Umbrales de pérdida, 144f Requerimientos de servicio de rendimiento bajo, 42 M Definición de mantenibilidad de, 49, 68, 118 medidas de 118 Mantenimiento, de la descripción del sistema de 52 nivel intermedio, preventiva 142, 140 reparación y piezas de repuesto para 142 apoyo concepto de enfoque de tercer nivel 142 – 143, 143 tipos de 137 – 138 Base de información de gestión 308, 322, 371 Gestión de requisitos, 107 – 108 Máscara Dirección Descripción de 251 modificación de supernetting de 265f natural, 257 – 258 Descripción de subred de 8 bits, de 260 – 261 263 4-bit, 262 – 263 supernet, 266 Puede opcional, 60 Tiempo medio entre fallos, 117 Tiempo medio entre fallos críticos de misión, 117 Tiempo promedio de reparación, 49, 118 Mecanismos de direccionamiento, 257 – 269 Descripción de, 215, 216, 217f, gestión de red 219. Ver Administración de red, mecanismos de rendimiento. Ver Rendimiento mecanismos de seguridad de enrutamiento, 269-277, 225 Metadatos, 321 Medición, 344-345 Definición de métricas de, 58 diseño, 393, 428-429 requisitos de red y servicio 428. Ver Validación de indicadores de servicio utiliza de, 429 MIB. Ver Base de información de gestión Tarifa de datos mínima, 131 Aplicaciones de misión crítica, 67 – 68 IP móvil, movilidad 221, 65 Modelado, para caracterizar el comportamiento, 113 – 114 Planificación y control de recolección de datos, definición de 304 – 305 de notificación de eventos 304, 86, análisis de tendencias de 306 – 307 307–308 Multicasts, 221 Multi-protocol label switching, 229, 255 Modelo de arquitectura multi-con gradas, 238 Desempeño de múltiples nivel, 103, 342–343 No / no 60 60 debe / / exigirá, N

NAT. Ver Traducción de direcciones de red Mascarilla natural, 257 – 258 Red información de planos Ver Anteproyectos capacidades de complejidad 19 – 20, 18 – 22 conectividad, las expectativas de clientes 256, 25 – 26 diseño de. Ver Diversidad de diseño a, 17f dinámica de 22 existentes. Ver Áreas funcionales de la red existente en 269, 270f, 289 funciones de, 212, 215 fondos de jerarquía 89 añadido a dependencias de interoperabilidad 16f, 85 diseño de. Ver Diseño de monitoreo de 26 obsolescencia de, 85 regiones, asignación de recursos 219, 41 efectos de la tecnología de tercera generación 21, 27 grupos de trabajo, 269, 270f Servidor de acceso de red, 374 Traducción de direcciones de red, 221, 269, 292, 373-374 Fondo de análisis de red de 3 – 6 definición de importancia 6 de 18 – 24 entradas y salidas, modelo 7f fines, 24 – 27 de 6 configuración para 4 Red de fondo de la arquitectura de componentes 3 – 6, 211-215. Ver Arquitecturas de componentes limitaciones, 102 de toma de decisiones sobre defensibility 23 de 22 – 24 definición de 7, 211 – 212 diseño y comparaciones entre 387f 213-215, objetivos, 226 entradas y salidas, información de ubicación de 8f necesaria para 214 modelo para, 24 – 27 conveniencia operacional afectada por, 134 – 136 rendimiento afectado por, costos postimplementation 84, 52 – 53 configuración para extracto 4 de 246 arquitectura de sistemas vs., 244–245 Diseño de la red. Ver Diseño Dispositivos de la red. Ver Dispositivo (s) Gestión de contabilidad, 312 abordar/enrutamiento de red y, interacciones entre 230, 292, 327 gestión empresarial, 300 categorías de 315 centralizado, 302, 326 cheques y balances, 319 composición de 302f gestión de configuración, 312 restricciones, gestión de 326 datos, 319-322 definición de, 300, 301 dependencias, 324-325 Descripción de, 222 223 distribuido, 316, gestión elemento 326 301 relaciones externas, 326 – 328 manejo de fallas, modelo FCAPS 312, 311-312 funciones de 302 jerárquica, 316-317, 326 jerarquía de 301f en banda, 312, 313, 325 fuentes de información, 299 interacciones, 323-324 relaciones internas, 323-326 capas de base, de la información de la gestión del 300-302 322 mecanismos de configuración, descripción de 310-311, 303 – 304 instrumentación, monitoreo de 308-310. Ver Monitoreo sistema de soporte de operaciones y, 323F, 323-324 fuera de banda, 313, 315, 325 rendimiento y, 327, gestión del desempeño 354, 312 seguridad y 85-87, 327-328, gestión de la seguridad 381, 312 gestión de servicios, 301 Resumen de, 328 compensaciones, 312, 325 – 326 tráfico escala, 318 – 319 Optimización de la red, 19 Red proyecto limitaciones, 102 – 103 alcance de, 101 – 102 tipos de, 101 Retardo de propagación de red, 126–127 Descripción de requisitos de, 18, 83-84 las redes existentes, la red métrica de 84-85 y, 428 Seguridad de la red. Ver Seguridad Servicios de red. Ver Servicio (s) Router de siguiente salto, 256

Tráfico de disconformes, 345 No en tiempo real aplicaciones, 71 Interfaz hacia el norte, 323 O Abrir ruta más corta primera abstracción de la zona, tiempos de convergencia 285, 284-285 definición de, 284 Descripción de 282 – 283 Definición de conveniencia operacional de, 88, 134 factores que afectan, 134 operaciones humana personal efecto, 136-137 efectos de diseño de arquitectura de la red, 134 – 136 Operaciones, administración, mantenimiento y aprovisionamiento de aplicaciones, 75, 82 Personal de operaciones, 136-137 Descripción de sistema de soporte de operaciones de gestión de red 185 y, 323F, 323-324 OSPF. Ver Abrir ruta más corta primero OSS. Ver Sistema de soporte de operaciones Gestión fuera de banda, 313–315, 325 Ruta de acceso fuera de banda, 86 Recubrimientos, 421 P Dirección de destino del paquete 254–255 expedición de 254 decisión local y remota para enviar, cola de 256 de 347 Filtrado de paquetes, 371 Paquete sobre SONET, 37 Topología, 416, 417f de malla-parcial Pathchar, 111 Tasa de datos máxima, 131 Interconexión, 222 Acuerdos de peering, 275, 277 Compañeros, 180 Modelo de flujo de peer-to-peer, 181 – 183, 234, 235, 235f Características por elemento, 303 Efectos de arquitectura de rendimiento en 84 definición de, 223, 224, 334 cifrado/descifrado efectos en 373 objetivos, 334 – 338 garantizado, 148 – 149 medidas de múltiples niveles de 106 – 107, 103, 342-343 predecible, solo nivel 147 – 148, 103, 342-343 Rendimiento arquitectura abordar/enrutamiento y 230, 292, 354 fondo de, definición de 334-335, 334 Descripción de, 223, 224, 229, 333 relaciones externas, relaciones internas 334, 354 – 355 fuentes de información, 354 mecanismos. Ver Mecanismos de funcionamiento Dirección de la red y, 327, 354 problemas dirigida por 337 de seguridad y, 355, 381 Capacidad de las características de rendimiento, 40, 47 confianza, 88 demora 48 Descripción de conveniencia operacional de 47 de 88 RMA, 48-50

capacidad de soporte, 88 Envolvente de funcionamiento, 50-51 Determinación de mecanismos de funcionamiento de necesidad, 336-337 evaluación de, 352-354 políticas, 351, 352f priorización, cola de 342, 343, 347-348 control de recursos, 342-351 de programación, 346-347 acuerdos de nivel de servicio, 19, 216, 224, 348 – 350 suficiencia de gestión del tráfico 338, 344-346 Seguridad perimetral, 373, 374, 378 Dirección persistente, 253, 254f Seguridad física, 368-369 Ping, 111, 128, 144 Protocolo punto a punto, 375, 376f Protocolo punto a punto sobre Ethernet, 375, 376f Descripción de las políticas de la arquitectura de rendimiento 274, 351, 352f seguridad, 224, 365-367 Intervalos de interrogación, 306 PPP. Ver Protocolo punto a punto PPPoE. Ver Protocolo punto a punto sobre Ethernet Performance predecible, 147-148 Solicitud de servicio predecible, 44 Servicios predecibles, 40 Calidad de la presentación, 65 Mantenimiento preventivo, 140 Definición de priorización de 342 de los flujos, 191 – 193 rendimiento y 342 – 343 proveedor, equipo de proveedores, y proveedor de servicios, 403–405 Privacidad, 225, 360 Privado abordar, 268-269 Dirección IP privada, 251, 253, 254f, 268 IP privada dirección, 221 Declaraciones de problema, 104 Componentes del proceso, 9 – 12 Descripción del proyecto planes de naturaleza iterativa 12 de 13 Retardo de propagación, 126 – 127 Protocolo de seguridad, 369-371 Dirección IP pública, 251, 253, 254f Infraestructura de clave pública, 372 Q Calidad de la definición de servicio de 338 Descripción de 19, 216, 224 IP, 338-342 Cola, 347-348 R Al azar detectar temprano, 348 Aplicaciones de tasa crítica, 67 – 69 Accesibilidad, 253-254 Análisis en tiempo real, 306 Aplicaciones en tiempo real, 67, 70 Banderas rojas, 106

De referencia la definición de la arquitectura de, 227 Descripción de, 213 desarrollo de, 239 relaciones externas, optimizando 229 de, 230 – 232 Confiabilidad como requisito de uso, 68 como exigencia del consumidor, definición 65, 68, 117 Descripción de, 48 – 49 Confiabilidad (continuación) tiempo medio entre fallos, 117 tiempo medio entre fallos críticos de misión, 117 medidas de 117 Diagramas de bloques de confiabilidad, 138, 139f Seguridad de acceso remoto, 226, 374–376 Piezas de repuesto, 142 Aplicación requisitos. Ver Aplicación requisitos capacidad 130 – 133 categorización de base 60, 58 – 59 definición de, retraso 58, 125 – 130 Descripción de dispositivo 57, 76 – 83 empresa, financiera, de 90 fundamental 89-90, 58 – 59 reunión de 61 rendimiento garantizado, 196 manejo de, 107 – 108 red. Ver Requisitos de la red Resumen de rendimiento suplementario 94 – 95. Ver Requisitos de rendimiento suplementario seguimiento de uptime de 107 – 108, 123 – 124 usuario. Ver Necesidades de los usuarios Expectativas de cliente de análisis de requisitos, definición 104, 58 ejemplo de, información de las expectativas de crecimiento 92 reunida durante, 278 condiciones iniciales, necesidad de 100-104, 61 – 62 envolvente de funcionamiento 200 medidas del desempeño, propósito de 106 – 107 de 61 esquema de 100f Resumen de 155 trabajando con usuarios, 105 – 106 Requisitos mapa, 62, 93f, 149-150, 151f Descripción de especificación de requisitos de, 62, 90-93 desarrollo de 151 – 154 ejemplo, 93f, 169 se reunieron y derivados requisitos incluidos 151 – 152 condiciones iniciales, 151 usuario cuestionario para determinar, 152f, 154f Asignación de recursos, 41 Control de recursos, 224 Protocolo de reserva de recursos, 340 Anillo topología, 415f, 416 Evaluaciones del riesgo, 400 RMA. Véase también Disponibilidad; Capacidad de mantenimiento; Descripción de fiabilidad de umbrales generales 48 – 50, 124 garantías, 124 requisitos, 117-125, métricas de servicio 138 para, soporte 110 afectado por 138–140 Retardo de ida y vuelta, 69, agregación de ruta 128 a 130, 274 Filtro de ruta, 273, 277 Filtrado, 221, 222, 273 de la ruta Router frontera, next-hop 286, 256 paquetes reenvío, 254 Routing. Véase también Fondo de direccionamiento, 250 – 251 classless interdomain, 267 componente plan, definición 420, 250 Descripción de 15 evolución de relaciones externas de 21, 22f, 292 – 293 fundamentos de, 253-257 las relaciones internas, los mecanismos de, 269-291 – 292 Dirección de la red de 277 y, 230, 292, 327 rendimiento y 230, 292, accesibilidad 354 aprendizaje, 253-254 seguridad y 230, 292, 380 – 381 ruta estática efectos, 283 – 284 estrategias, 280 – 290 conmutación vs 255 Algoritmos de encaminamiento, 284 Enrutamiento definición de límites de 270 zona desmilitarizada, 271 – 272 duro, 271, 273 importancia de 272 lógica, física 270, suave 270, 271, 272 Flujos de enrutamiento predeterminada ruta, 273 definición, 272 establecimiento de manipulación de 269, 270, 273 – 277

Protocolos de información de encaminamiento, 21, 282, 284 Enrutamiento de la aplicación de protocolos de, 287 – 290 convergencia tiempo para 281 criterios de 281 vector de distancia algoritmo de enrutamiento utilizado por, 284 diversidad, 281, 285f dinámico, 283 evaluación de, 281-286, 290f protocolos de portal exterior, 271, jerarquía 284, 281, 285f fuentes informativas, 249 – 250 protocolos de gateway interior, 284 – 285 271, interoperabilidad de 281 algoritmo de enrutamiento de estado de enlace utilizado por 284 accesibilidad aprendido utilizando, selección 253 de 281, 287 – 290 tipos de 271 S Programación, 346-347 Producto del diseño de segundo orden, 388, 388f Biblioteca de sockets seguros, 373 Abordar/enrutamiento de seguridad y, 230, 292, 380 – 381 aplicación, datos 369-371, definición 363, 359 Descripción de, 65, 225, 226, 229, 359 desarrollo de cifrado y descifrado de 361-362, 371 – 373 evaluación de relaciones externas de 377 – 380, 380 – 381 fuentes de información, relaciones internas 359-360, 380 dirección de la red y, 381 327 – 328, rendimiento y, 355, 381 perímetro, 373-374, 378 física, plan de 368-369, 361-362 políticas y procedimientos, 225, 365 – 367 privacidad, 225, protocolo 360, acceso remoto 369-371, 374-376 análisis de amenazas, 225, 362-365 Conciencia en seguridad, 369 Evaluación de riesgos de seguridad, 87, 87f Zonas de seguridad, 225, 355, 378–380, 379f Siembra, 397 Servidores, 78 Servicio (s) el mejor-esfuerzo, 32, 39-40 definición de, 31, 37 Descripción de 31 garantizado, 39 – 40 naturaleza jerárquica de, 32, 32f, 40 predecible, 34 – 35 Configuración de características del servicio de 36 – 37 definición de 33 "end-to-end" aprovisionamiento de, ejemplo 33 – 34 de 33 niveles, componentes del sistema de 35 – 36, 36 – 39 Acuerdo de nivel de servicio, 19, 149, 216, 224, 348–350 Niveles de servicio, 35 – 36 Gestión del servicio, 301 Aplicación de métricas de servicio de, 112-113 para capacidad 110 definición de 33 por retraso, 110 Descripción de desarrollo 155, 109 – 113 de los límites de servicio medido utilizando, 45 herramientas de medición 111 – 112 para RMA, 110 los umbrales medidos usando, 45 variables utilizan como, 111 Servicio de ofertas, 33, 43 – 45 Plan de servicio, 197 Proveedor de servicios de modelo arquitectónico, 237 Candidatos de proveedor de servicios de evaluaciones, 398-399, 405-407 refinamiento de criterios, datos 401 – 403, 399 – 401 Descripción de, 392, 393, 395 – 397 orden de priorización 407, 403-405 ratings, 401-405 siembra el proceso de evaluación, 397 – 398 Resumen calificaciones, 405 Servicio pide esfuerzo, definición 44, 33, 36 garantizado, predecible, 40 40

Servicio requisitos de alto rendimiento 42 rendimiento bajo, 42 Formar, de tráfico, 345 Debe no recomendado, 60 / La recomienda, 60 Protocolo simple de administración de red, 111, 303 – 304 Caracterización de la simulación de comportamiento usando, 113 – 114 modelado climático, 187 proveedores, proveedores equipos y selecciones de proveedor de servicios usa, 400 Modelo arquitectónico de la solo-con gradas, 238 Rendimiento de la solo-grada, 103, 342 SNMP. Ver Protocolo simple de administración de red Límites blandos, 271-272 Piezas de repuesto, 142 Especializada de dispositivos, 78 – 79, 79f Rutas estáticas, 283 Almacenamiento de archivos, 305 Red de área de almacenamiento, servidores de almacenamiento 31, 78 lugares estratégicos, 411, 414 Red de trozo, 283 Creación de la subred de 261 definición, asignación de grupo de trabajo 260 de 262 Descripción de máscaras de subred de 260 – 261 8-bit, 263 4-bit, 262-263 Subredes Descripción de, 259 – 261-de longitud variable, 221, 262-264, 279, 280f Sistema de gestión de abonado, 374 Máscara de Supernet, 266 Superredes, 264 Requisitos de rendimiento suplementario confianza, 88, 134, 143 – 145 Descripción de, 88 – 89 desarrollo de idoneidad operativa 133-145. Ver Soporte de conveniencia operacional. Ver Capacidad de soporte Capacidad de soporte como característica de funcionamiento, 88 definición de 134 factores que afectan la descripción de la documentación 137, 140 RMA, 138-140 procedimientos del sistema, 141 herramientas, 141-142 empleados, 140 red, 51 – 53 necesidades de los usuarios para, 66 Tasa de datos constante, 131 Conmutación, 221, 250, 255 Sistema autónomo, 17, 270-271, 274, 286 componentes del 28f, 29 definición de 27 Descripción de elemento de conocimiento humano 27 – 31 de 52 costos de ciclo de vida de, 51 – 52 mantenimiento elemento elemento, 52 operaciones de visión tradicional 52 de 30, 30f Interrupciones en el sistema, 120 Arquitectura de sistemas, 244-245 Metodología de sistemas, 27 T Forma tabular, de seguimiento y gestión de requisitos, 108, 108f Reconocimientos TCP, 349 TCPdump, 111

TCP/IP, 130, 249 Documentación técnica, 140 – 141 Telelearning, 182 – 183 183f Telemetría, 73 – 74 Tele * servicio de aplicaciones, 75, 182 Telnet, 72 Dirección temporal, 253, 254f Redes de tercera generación, 27 Producto del diseño de tercer orden, 388-389 Análisis de las amenazas, 225, 362-365 Los umbrales de retrasan, 126 – 127, 129-específicas del entorno, 117, 124, 145 – 147 general. Ver Pérdida general de umbrales, 144f Requisitos de RMA, 124 – 125 indicadores de servicio para la medición, 45, 109 uptime, 120 – 121 Puntualidad, 64 Modelos topológicos, 232-234 Topología, 414, 417, 416f, 418f Trazabilidad de diseño definición de 393 para educar nuevos empleados sobre la evolución en el diseño, 426 – 427 ejemplos de indicaciones 423f – 424f, 425 – 427 métricas alinean con requisitos, 429 Traceroute, 111 Seguimiento de requisitos, 107 – 108 Ventajas y desventajas Descripción de, 215, 217 de cifrado/descifrado, administración de redes 373, 312, 325 – 326 Tráfico de acondicionado, 344, 346f Tráfico flujos, 344. Véase también Flow(s) Gestión del tráfico, 344-346 Protocolo de transporte, 131 Trampa, 304 Análisis de tendencias, 307 Solución de problemas, 311 El hacer un túnel, 369-370 U Flujo unidireccional, 163, 164f Definición de tiempo de actividad de, 119 medida de extremo a extremo de, 123 General umbrales 120, 121, 124 Medición de, 121 – 124 requerimientos de performance y, 120 para, 123 – 124 Comunicación de usuario con 105 definición de privacidad 62 de 225 trabajando, comportamiento del usuario 105, 106, 115, 116 Protocolo de usuario diagrama, 144 Adaptabilidad de requisitos de usuario, accesibilidad 65, 65 – 66 definición de, 62 funcionalidad, interactividad 66, movilidad 64 – 65, 65 calidad de presentación, finalidad 65, 63 fiabilidad, seguridad 65, 65 soporte, puntualidad 66, 64 tipos de 63f V Subnetting de longitud variable, 221, 262, 264, 279, 280f Proveedores y las evaluaciones de equipos proveedor candidatos, 398, 399, 405-407 refinamiento de criterios, datos 401 – 403, 399 – 401 Descripción de, 392-393,

395 – 397 orden de priorización 407, 403-405 ratings, 401-405 siembra el proceso de evaluación, 397 – 398 Resumen calificaciones, 405 Virtual private networks consideraciones sobre la arquitectura 375 – 376 Descripción de 4 túneles por 370 Lenguaje de marcado de realidad virtual, aplicaciones de visualización 69, 74 Voz sobre IP, 13, 42 VPNs. Ver Redes privadas virtuales W WAN arquitectura del 386, 387f Descripción de tráfico 83 escala, 319 Desarrollo Web, acceso y usos, 74 348 cola, justa ponderada Weighted random detectar temprano, 348 Red de área inalámbrica. Ver WAN Grupos de trabajo, 269, 270f

Esta página dejada intencionadamente en blanco