Network Analysis Architecture and Design

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: permissions@elsevier.com. 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
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.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.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.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.6 Conclusions 328
7.7 Exercises 328
8 Arquitectura de rendimiento
8.1 Objectives 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.1 Evaluación de desempeño mecanismos 352
8.6 Conclusiones 355
8.7 Ejercicios de 356
Contenido
9 Arquitectura de la privacidad y seguridad

9.1 Objetivos 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.1 Evaluación de mecanismos de seguridad 377
9.7 Conclusiones 381 9,8 ejercicios 382
10 Diseño de redes
10.1 Objetivos 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
doowah_1@yahoo.com 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.
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
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
Relaciones entre clases de equipos de red funciones
FIGURA 1.3 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 High-
End 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
Dispositivo de
Enlace de
datos
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
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
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.
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
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 end-
to-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-to-
end, 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 Tipo
Procesador OS Aplicaciones
dispositivo NIC
PC gama 10M Win95/98/2000 Palabra, PP,

Pentium I
baja Ethernet finanzas
Ethernet Pentium Palabra,
PC alta
de 10 / III Y IV WinPro gráficos PP,
gama
100M DB,
Ethernet Win95/98/2000/XP Palabra,
PC genérico de 10 / Pentium gráficos PP,
100M DB,
Ethernet DB, gráfico,
Estación de
de 10 / AMD Linux CAD, SC
trabajo
100M
Ordenador 56 Kb Palabra, PP,

AMD Win XP
portátil Módem 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 / Dispositivos Elementos
Servidores Software Servicios Datos
probabilidad de usuario de la red
Acceso no
B/A B/B C/B A/B BYC A/B
autorizado
Divulgación no
BYC B/B C/C A/B BYC A/B
autorizada
Denegación de
B/B B/B B/B B/B B/B D/D
servicio
Robo A/D B/D B/D A/B C/C A/B
AIRE
Corrupción BYC C/C A/B D/D A/B
ACOND.
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
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 Se reunieron
Fecha Tipo Descripción Lugares Estado Prioridad
nombre / derivados
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
ID / Se
Nombre reunieron/derivados
Distribución de usuario es: 60

14 01 de ingenieros, 15 HR y finanzas, Reunidos desde
1 Usuario Ver mapa Información TBD
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 Todos
2 12Jan01 Red Conexiones rápidas de Ethernet a la TBD TBD
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 Ver mapa TBD TBD
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 Ver mapa TBD TBD
usuarios (hombre)
determinados en este momento
Aplicación de base de datos (DB1)

14 01 de Se reunieron de
5 Aplicación requiere un mínimo de 150 Kb/s, por TBD TBD TBD
ene Varios usuarios
sesión
Los usuarios de ingeniería tienen

02 01 de Dispositivo Recogidos de los
6 estaciones de trabajo con NIC Ver mapa TBD TBD
Feb de usuarios (ENG)
GigE
Aplicación de visualización (VIS1) de

finanzas requiere de hasta 40 Mb/s Derivados de la
7 20Jan01 Aplicación Ver mapa TBD TBD
capacidad y 100 ms de retardo ida y aplicación
vuelta
Aplicación de nómina (PAY1)

11 01 de requiere 100% uptime (mientras está Reunidos desde
8 Aplicación Ver mapa TBD TBD
Feb en funcionamiento) entre finanzas y la administración
nómina fuera empresa
Compañía debe estar segura de Reunidos desde

9 12Jan01 Red TBD TBD TBD
Ataques de Internet la administración
02 01 de Empresa requiere un mínimo de T1 Obtenida de la

10 Red Ver mapa TBD TBD
Feb acceso a Internet red personal
Red actual completamente

02 01 de Obtenida de la
11 Red reemplazará, por lo que hay no hay N/A Información TBD
Feb red personal
requisitos de red existente
Otras aplicaciones generales:

correo, procesamiento de textos, Obtenida de la
12 20Jan01 Aplicación TBD TBD TBD
acceso a la web interna y red personal
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

Fabricación de
(InternetConexión)
(30 usuarios)
(Aplicación de inventario)
(Fast Ethernet para BB)
Vestíbulo Zona
Edificio A, 2ª planta
Recursos humanos y
finanzas De la ingeniería
(15 usuarios)
De la ingeniería
(Aplicación de nóminas
(60 usuarios)
Uptime del 100% cuando
(Aplicación de
está activo) Ventas y Marketing
visualización
(Fast Ethernet para BB) (30 usuarios)
40 Mb/s, 100 retraso de
(Fast Ethernet para
ms)
BB)
Gestión (NICs GigE)
(10 usuarios) (Fast Ethernet para BB)
(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 Red de rendimiento solo nivel: Ningún distintivo
o unos aplicaciones, grupos de usuarios o 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 Descripción
Todo el equipo de red deberá ser capaz de

actualizaciones basado en software que le
Texto
01Jan2007 permita soportar los cambios a las
original en
características del servicio de datos de alta
velocidad y funciones.
07 de
"Todos los equipos de red" cambiaron a
marzo de Cambio
"Tecnología"
2007
NR - 1.0-102
01 de abril "basados en software upgrades" cambiaron a
Cambio
de 2007 "software o actualizaciones de firmware"
17 de abril
Eliminación Cambio del 01 de abril de 2000 eliminado
de 2007
20 de
mayo de Cambio "alta velocidad" cambió a "cualquiera"
2007
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étodo de
Métricas de servicio Donde se medirán en sistema métrico
medición
Entre dispositivo de NM y cada Router
1 Retraso de LAN Ping
en LAN
Entre dispositivo de NM y la interfaz

2 WAN retardo 1 Ping
Local del Router para WAN
Entre NM dispositivo y el Router remoto

3 Retraso WAN 2 Ping
Interfaz WAN
Pérdida de
4 paquetes de la En cada Router Local SNMP
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%.
%
Cantidad de tiempo de inactividad permitido en
Tiempo
Horas (h), minutos (m) o segundos (s) por un periodo de
de
tiempo
actividad
Anual Mensual Semanal Diario
99% 87.6 h 7.3 h 1.68 h 14.4 m
99.9% 8.76 h 44 m 10 m 1.4 m
99.99% 53 m 4.4 m 1m 8.6 s
99.999% 5.3 m 26.3 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
Medio tiempo Datos promedio

Aplicación
(segundos) tamaño (Bytes)
Distribuido de
103 107
computación (lotes)
Transacciones Web 10 104
Las entradas y consultas 103

2–5
de base de datos
Entradas nómina 10 102
Teleconferencia 103 105
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 final-
deshilachadas 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 Aprobado por el
Artículo / Falta Misión Falta

Disposiciones
Identificación Modos Fase o Efecto Final Detección Clase de
ID Función de Observaciones
funcional / y Modo local Efectos de severidad
compensación
Nomenclatura Causas op Modo de
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.
Herramientas y Mantenimiento Mantenimiento

Nivel Ubicación Quién
equipos de prueba correctivo preventivo
• Herramientas comunes • Seguimiento día a día • Vigilancia del desempeño
• Controles y consolas • Solución de problemas de
Sitios de las Operadores de operador • Aislamiento de fallas • Menor limpieza in situ y

Organizacional
operaciones de • Baratos herramientas • Sustitución de remotas ajustes
especiales • Reconfiguración del • Reemplazo programado
sistema de remotas
El llamado a Con personal Especiales o costosas Reparación in situ de

Inter- • Actualizaciones in situ
trabajar en el capacitado herramientas portátiles offline
mediar en mayores donde es
sitio que con uso limitado equipo
función impráctico el envío a
primordial es fábrica
el • Operadores de
mantenimiento suplemento
Personal del Equipo para la

Proveedor o Revisión programada o el
Depot proveedor o renovación de Revisión y renovación
fábrica desmontaje de remotas
fábrica componentes
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
Tiempo Total máximo
paquetes (% de tráfico de
(por semana)
la red Total)
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
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
Financiera TBD
Condiciones
Rendimiento de la aplicación ha sido un problema recurrente, gestión quiere

Definición y evaluación
actualizar la red y ha sugerido actualizar interfaces Fast Ethernet. Algunos
del problema
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
Sección 2: Lista de los requerimientos
ID / Se reunieron /
Nombre derivados
Distribución de usuario es: 60

14 01 ingenieros, 15 HR y finanzas, Reunidos desde
1 Usuario TBD Información TBD
de ene fabricación, gestión de 10, 30 la administración
Marketing y ventas, 5 de 30 otros
Debe apoyar cada área del edificio

14 01 Reunidos desde
2 Red Conexiones rápidas de Ethernet a la TBD TBD TBD
de ene la administración
red troncal
Aplicaciones de base de datos,

14 01 Reunidos desde
3 Aplicación visualización, fabricación y nómina TBD TBD TBD
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 requiere 100% uptime (mientras está Reunidos desde
4 Aplicación TBD TBD TBD
de ene en funcionamiento) entre finanzas y la administración
nómina fuera empresa
14 01 Compañía debe estar segura de Reunidos desde

5 Red TBD TBD TBD
de ene Ataques de Internet la administración
Requisitos de la figura 3.29 se reunieron desde la reunión inicial con el cliente
Desarrollo de la especificación de requisitos
¿Con qué ¿Por cuánto

1. aplicaciones lista que utilizas frecuencia? (veces tiempo cada
al día) vez?
Aplicación 1-
Aplicación 2-
Aplicación 3-
Aplicación 4-
Aplicación 5-
2. lista de equipos u otros dispositivos que

Interfaz de red Sistema operativo
utilizan conectados a red
Dispositivo 1 (escritorio o portátil)-
Dispositivo 2-
3. ¿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)
Rendimiento-
Características-
Otros-
5. ¿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
Parte 2: Listado de requisitos
ID / Se reunieron /
Nombre derivados
Inventario de aplicación (INV1) Recogidos de

6 20Jan01 Aplicación para la fabricación de requisitos no los usuarios TBD TBD TBD
determinados en este momento (hombre)
Recogidos de
Dispositivo Los usuarios de ingeniería tienen
7 25Jan01 los usuarios TBD TBD TBD
de estaciones de trabajo con NIC GigE
(ENG)
Otras aplicaciones generales:

02 01 de correo, procesamiento de textos, Obtenida de la
8 Aplicación TBD TBD TBD
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.
Parte 2: Listado de requisitos

ID / Se
Nombre Fecha Tipo Descripción reunieron / Lugares Estado Prioridad
derivados
Aplicación de base de datos (DB1)

Reunió de
9 01Feb01 Aplicación requiere un mínimo de 150 Kb/s por TBD TBD TBD
varios usuarios
sesión
02 01 de Empresa requiere un mínimo de T1 Obtenida de la

10 Red TBD TBD TBD
Feb acceso a Internet red personal
Red actual completamente

02 01 de Obtenida de la
11 Red reemplazará, por lo que hay no hay N/A Información TBD
Feb red personal
requisitos de red existente
Aplicación de visualización (VIS1) de

finanzas requiere hasta Derivados de
12 05Feb01 Aplicación TBD TBD TBD
40 Capacidad de mb/s y 100 ms 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 Set 1:
Aplicación 1 150 Kb/s N/A N/A
Aplicación sistema 2:
Aplicación 1 75 Kb/s 99.999% N/A
Aplicación 3 250 Kb/s 99.999% N/A
Aplicación Set 3:
Aplicación 1 1.1 Mb/s 99.95% 40 ms
Aplicación 3 950 Kb/s N/A 100 ms
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.

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)
Retardo (p. ej., latencia)

Requisitos de
desempeño Fiabilidad (por ejemplo, la disponibilidad de)
Calidad de niveles de servicio
Importancia / Proveedor de empresa de negocios

niveles de
prioridad 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
ID Requisitos de desempeño Número

de de
flujo Fiabilidad Capacidad Retardo 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

de de Presupuesto Prioridad
Fiabilidad Capacidad Retardo
flujo usuarios
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

Figura 4.34 corrientes priorizadas por el número de usuarios servidos

de de Presupuesto Prioridad
Fiabilidad Capacidad Retardo
flujo usuarios
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

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 Tipos de flujos Descripción del
de flujo funcionamiento
Compuesto y esfuerzo
Una sola pieza Capacidad sólo
Individual
Best-Effort y estocástico, Confiabilidad,
Dos partes
individuales y compuestos capacidad y retraso
Best-Effort, estocástica y
garantizada, Confiabilidad,
Varias partes
Individuales y capacidad y retraso
compuestos
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 320 100
Archivos de actualización 1600 1000
Archivos finales 160 105
Resultados de flujo de tipo 1600 100

1
F1: Flujo tipo 2


2
Resultados de la F1 1760 100
Resultados de la F2
1760 100
Resultado para F3
1760 100
F4: Flujo tipo 1
1600 100
F4: Flujo tipo 2

2
Resultados de F4 2240 100
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?

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
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
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
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

agregar espacio de direcciones
Provee conectividad robusta y flexible
Abordar/enrutamiento • Routing: Routers, protocolos de
entre los dispositivos
enrutamiento, formas para
manipular flujos de enrutamiento
• Protocolos de gestión de red
• Dispositivos de administración de
Administración de Proporciona monitoreo, configuración y
red
redes solución de problemas de la red
• Maneras de configurar la gestión de
la red en la red
Proporciona recursos de la red para • Calidad de servicio

Rendimiento soportar los requerimientos de • 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 • Procedimientos y políticas de
Seguridad
reducir la amenaza y los efectos de los seguridad
ataques • 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

Por
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 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?
¿Dependencias de la política Políticas de

de QoS, por ejemplo, una
Dependencias de la política
política puede ser exigible a
de SLAs
través de mecanismos de QoS Figura 5.7 una muestra del gráfico
disponibles? 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 internas Relaciones externas

(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.

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-to-
end-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.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
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.
Potencia de 2
27 26 25 24 23 22 21 20
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 00 0 0 1 1 0 0 0 11 0 0 00
0
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 que son reconocidas localmente, en la LAN

o
Direcciones locales
subred. Estas direcciones están generalmente en la
capa de enlace de datos (por ejemplo, Ethernet).
Direcciones que son reconocidas en todo el
Direcciones globales de mundo. Estas direcciones están generalmente en la
capa de red (IP).
Direcciones de capa de red que no se enrutan a través
Direcciones privado de la Internet pública. Direcciones privadas se utilizan
en la traducción de direcciones de red (NAT).
Direcciones de capa de red que se enrutan a través de

Direcciones públicas
la Internet pública.
Direcciones que se asignan por un corto período de

tiempo,
Direcciones temporales
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
Direcciones de persistente 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
11
0
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 1 0 0 0 1 0 0 000 0 0 0 0 0 0 0 1
11
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
Máscara natural (binario)

1111111 11111111 1111111 0000000
1 1 0
Dirección 192 de red 92 240 0

(Decimal)
1100000 01011100 1111000 0000000
Dirección de red (binario)
0 0 0
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
Máscara de Supernet (binario)

1111111 11111111 1111000 0000000
1 0 0
Reconocido
Dirección 192 de red 92 240 0

(Decimal)
1100000 01011100 1111000 0000000
Dirección de red (binario)
0 0 0
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 1 Conexión No hay

diversidad
2 Conexiones, (Sin redundancia)
2 Niveles Baja jerarquía
Altamente asimétrica
de
Baja diversidad
Jerarquía medio 2 conexiones,
3 a 5 niveles Ligeramente asimétricos
2 o más conexiones, Diversidad media
Alta jerarquía
simétricas
> 5 niveles
(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.

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 Ubicación Departamento Usuarios de

número de de
Campus de Legal 120

Chicago
Edificio 1 Contabilidad 370
1
HQ 1580
Campus de
Chicago
De la 200
Edificio 2
ingeniería
Toronto Ventas 75
2
Boston Ventas 110
Operations1 2150
3 Philadelphia Operations2 975
Ventas 575
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

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.6 Conclusions
7.7 Exercises
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
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 Número de bytes recibidos
ifOutOctets Número de bytes enviados
ifInUcastPkts Número de paquetes de unidifusión recibidos
ifOutUcastPkts Número de paquetes de unidifusión enviados
ifInNUcastPkts 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.

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.

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/por-

red/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 Dispositivos de usuario Dispositivos de red

Todos los dispositivos emitidos cada Dispositivos de usuario 1500 25 dispositivos de red
15 segundos 1 interfaz por dispositivo 4 interfaces por
100% de los encuestados datos 6 variables por interfaz dispositivo
almacenados 64 bytes por Variable 10 variables por interfaz
Almacenamiento para 2 años de 64 bytes por Variable
continua interrogación
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.
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.1 Evaluación de los mecanismos de funcionamiento de
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
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-to-
end 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.
Servicios diferenciados Servicios integrados

Función/característica
(DiffServ) (IntServ)
Escalable a grandes empresas Limitadas a pequeñas o

Escalabilidad
de redes de servicios medianas empresas redes
Granularidad del Control Tráfico agregado en clases Por flujo o grupos de flujos de
Todos los dispositivos en

Por dispositivo de red (por
Alcance de Control camino extremo-extremo del
salto)
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-to-
end. 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 Capacidad Rendimiento del Fiabilidad
servicio: desempeño retardo Rendimiento
Como disponible Como disponible Como disponible
Servicio básico
(mejor esfuerzo) (mejor esfuerzo) (mejor esfuerzo)
1.5 Mb/s Como disponible Como disponible
Servicio plata
(bidireccional) (mejor esfuerzo) (mejor esfuerzo)
10 Mb/s Max 100 Ms ida y vuelta Como disponible

Servicio oro (bidireccional) (Burst (entre puntos (mejor esfuerzo)
100 Mb/s) especificados)
100/10 Mb/s hacia MAX 40 Ms ida y vuelta 99.999% uptime
Servicio platino arriba o hacia abajo (entre puntos (servidor, usuario)
(explosión a 1 Gb/s) especificados)
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.

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).

En el desarrollo de nuestra arquitectura de rendimiento que debemos evaluar mecanismos
potenciales de rendimiento, determinar donde puede aplicar dentro de la red,
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
(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).

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.

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.1 Evaluación de mecanismos de seguridad
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
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 / Hardware Dispositivos

probabilidad del Servidores de red Software Servicios Datos
usuario
Acceso no
B/A B/B C/B A/B BYC A/B
autorizado
Divulgación no
BYC B/B C/C A/B BYC A/B
autorizada
Denegación de
B/B B/B B/B B/B B/B D/D
servicio
Robo A/D B/D B/D A/B C/C A/B
AIRE
Corrupción BYC C/C A/B D/D A/B
ACOND.
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
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: Fuente:
d 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.

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)
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.

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.

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
Seleccionado
Priorizadas Arquitectura de referencia
Candidato
Candidatos
Candidato
1) DD
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
Peso
Criterios de evaluación
relativo Candidato Candidato Candidato Candidato Candidato
1 2 3 4 5
1 Costos iniciales
2 Costos recurrentes
3 Tecnologías
4 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 Candidatos
Criterios de evaluación relativo (0-

1) Candidato 1 Candidato 2 Candidato 3 Candidato 4 Candidato 5
1 Costos iniciales 0.8
2 Costos recurrentes 1.0
3 Tecnologías 0.5
4 Cumplimiento de las 0.2

normas
5 Riesgos 0.9
6 Rendimiento 0.8
7 Servicios disponibles 0.2

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 Candidatos
Criterios de evaluación relativo (0-

1) 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
4 Cumplimiento de las 0.2 4/0.8 1/0.2 3/0.6 2/0.4 5/1.0

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
Estadísticas totales de candidato 34/17.6 31/21.6 24/12.7 19/10.9 27/12.2
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 Candidato
Relativa Total
1 Candidato 2 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 co-
ubicació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
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?
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.
Glosario de siglas
AAAA autenticación, autorización, contabilidad y
asignación
ABR 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
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
CBC Cipher block encadenamiento
CBQ colas basadas en clases
451
CBR tasa de bits constante

CD disco compacto
CDN red de distribución de contenido
CDR revisión crítica de diseño
CF flujo compuesto
CHAP Protocolo de autenticación de desafío y
respuesta
CIDR 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 arquitectura de intermediario de petición de
objeto común
CoS 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 Protocolo de configuración dinámica de
Host
DiffServ servicios diferenciados
DMZ zona desmilitarizada
DNS sistema de nombres de dominio
DR. Ruta por defecto
DSCP punto de código de servicios diferenciados

DSL bucle de abonado digital
DSx digital de señal (x =1, 3)

ESD unidad de servicio de datos
dWDM 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 fallas, configuración, contabilidad, desempeño y
seguridad
FCIP 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 equivalente/tiempo completo empleado de tiempo
completo
FTP Protocolo de transferencia de archivos
FY año fiscal
GB/s gigabits por segundo

GigE 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
TERAPIA DE tiempo de respuesta humana
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 Protocolo de mensajes de Control
Internet
ID 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
ENTRADA- entrada/salida
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 kilobits por segundo

KB/s 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
LEC Cliente de emulación de LAN
LECS Servidor de conexión de emulación
de LAN
LES Servidor de emulación de LAN
LIS subred IP lógica
LLNL Laboratorio Nacional de Lawrence
Livermore
LOH 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
MPOA multiprotocolo sobre ATM
RESONANCIA la proyección de imagen de resonancia
MAGNÉTICA magnética
MS milisegundos
TIEMPO MEDIO tiempo medio entre fallas
ENTRE FALLOS
MTBCF tiempo medio entre fallos críticos
MTBSO tiempo promedio entre la interrupción del
servicio
TIEMPO MEDIO tiempo medio para reparar
DE
REPARACIÓN
NA o N/A no disponible
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 operaciones, administración y

mantenimiento
OAM & P OAM y la provisión
OCx portador óptico (x =1, 3, 12, 24, 48, 192)

OLTP procesamiento de transacciones en línea
ORR Informe operacional
OS Sistema operativo
OSPF Protocolo de enrutamiento de primera

de camino más corto abierto
OSI interconexión de sistemas abiertos
OSS sistema de soporte de operaciones
P peering
PADI Iniciación de PPPoE active discovery

PADO Oferta de PPPoE active discovery
PADRI Solicitud de descubrimiento activo de
PPPoE
COJINES Sesión de descubrimiento activo de
PPPoE
PAP Protocolo de autenticación de
contraseña
PC ordenador personal
PDA Asistente personal digital
PDP punto de decisión política
PDR tasa de datos máxima; revisión de
diseño preliminar
PEP 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
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 investigación y desarrollo

RA agregación de ruta
RADIO servicio de acceso remoto dial-en
usuario
RBD 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
RIP Protocolo de información de
enrutamiento
RMA confiabilidad, mantenibilidad y
disponibilidad
RMON 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
SHA algoritmo hash seguro

SIP 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 servidor multicast especial, sistema de gestión de
abonado
SNMP 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 interfaz de usuario

USUARIO
UID ID de usuario
UPS fuente de alimentación ininterrumpida
USM modelo de seguridad basado en el usuario
VBR tasa de bits variable
VLAN LAN virtual
VLSM máscara de subred de longitud

variable
VoIP voz sobre IP
VPN red privada virtual
VRML Lenguaje de marcado de
realidad virtual
WAN red de área amplia
WDM multiplexación por división de

longitud de onda
WFQ weighted fair queuing
WG Grupo de trabajo
WRED weighted random detectar
temprano
xSP proveedor de servicios (varios)
Í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, 238-
244
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 24-
27. 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, 260-
261
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
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

Network Analysis Architecture and Design

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Network Analysis Architecture and Design

Caricato da

Copyright:

Formati disponibili

Análisis de redes, arquitectura y

La serie de Morgan Kaufmann en redes

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

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:

John Evans y Clarence Filsfils

Ingeniería de tráfico y QoS optimización de integrado

Voz y redes de datos

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

Michał Pióro y Deepankar Medhi

Redes privadas virtuales: la conexión derecha Dennis Fowler

Aplicaciones en red: Una guía a la informática nuevo

Redes de comunicación: un enfoque analítico Anurag Kumar, D. Manjunath y alegría Kuri

Internet y sus protocolos: un enfoque comparativo

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

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

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,

Francisco • Singapur • Sydney • Tokio

Adquisiciones Editor Rick Adams

Morgan Kaufmann Publishers es una impresión de Elsevier. 30 Corporate

papel libre de ácido.

© 2007 Elsevier Inc. Todos los derechos reservados.

Biblioteca de datos de catalogación en publicación de Congreso (Solicitado)

Impreso en los Estados Unidos de América

Trabajando juntos para hacer crecer las

Esta página dejada intencionadamente en blanco

Departamento de comercio de John McManus, Estados Unidos

Esta página dejada intencionadamente en blanco

2 Análisis de requerimientos: conceptos

3 Análisis de requerimientos: proceso

Métricas de servicio en desarrollo 3,3 109