An

1
Análisis de RequerimientosPAUTAS

• Las pautas para el análisis de requerimientos son
  parte del modelo del proceso. Este modelo,
  mostrado en la siguiente figura, muestra los
  pasos principales en la colección y análisis de
  requerimientos para su diseño de red.

2
Análisis de RequerimientosPAUTAS
3
Determinar Condiciones Iniciales

• Tipo de diseño del proyecto
• Nuevo diseño
• mejorar una red existente
• contratar a un outsourcing
• Dimensionamiento
• Tamaño de la red
• Geográfico
• Financiero

4
Condiciones Iniciales

• Objetivos del diseño inicial (si está disponible)
• Fuerzas externas/restricciones
• Politico - Quien está a cargo?
• Administrativo - Comité que toma decisiones?
• Evaluación de la situación existente
• Porque estamos haciendo esto? Que tiene de errado
  la red del sistema existente?

5
Desarrollar Métricas de Servicio

• Métricas para Confiabilidad
• Disponibilidad
• Estabilidad (MTBF,MTTR)
• Características de Transmisión
• Razón de Error de bits
• Razón de Pérdida de Celdas
• Razón de Pérdida de Paquetes/frames

6
Métricas de Servicio

• Métricas de Capacidad
• Razón de Datos
• Razón de datos peak
• Razón de datos sostenido
• Tamaño de los datos
• Tamaño de ráfaga y duración
• Tamaño del paquete/frame promedio y Máximo
• Distribución del tamaño de paquetes
• Tamaño de la Transacción

7
Métricas de Retardo

• Extremo a Extremo / Ida y Vuelta
• Tiempo de respuesta del sistema host
• Variación del Retardo
• Variaciones con condiciones de cambio de red

8
Herramientas de Medición en Red

• Contadores SNMP en hubs/switches
• cuenta el tránsito de los paquetes
• Paquetes enviados
• Paquetes eliminados
• Errores
• Monitores Externos
• Remote MONitoring (RMON)

9
Herramientas de Medición en Red

• Herramientas simples de Software
• Ping
• Netperf
• Herramientas de Análisis

10
Monitor de Rendimiento entre redes
CiscoWorks Blue Internetwork Performance Monitor

• Localiza cuellos de botella de rendimiento
• Provee alta disponibilidad de la red
• Administración de Rendimiento Proactivo
• Análisis de Tendencia en Rendimiento
• Análisis de Rendimiento de redes mezcladas SNA/IP
• Aumenta el operador de productividad
• Redundancia, seguridad, y verificación

2
11
Localizar Cuellos de Botella en Rendimiento
Usuario final
IPM

• Análisis de Rendimiento Salto a Salto a través de
  la red

12
Análisis de Rendencia de Rendimiento

• Chequea la red por períodos largos de tiempo
• Muestra los tiempos máximos de respuestas
• Muestra los tiempos mínimos de respuestas
• Muestra tiempos de respuesta promedio
• Muestra errores que podrían contribuir a tiempos
  de respuestas pobres

13
Redundancia, Seguridad y Verificación

• Identifica trayectorias redundantes en la red
• Estima la utilización de rutas redundantes

14
Usando Ping y Pérdida de paquetes IP como medidas
de Confiabilidad
15
Tabla de métrica de Servicio
16
Caracterizar el Comportamiento

• Patrones de uso
• Los patrones del uso pueden incluir para cada
  aplicación el número total de usuarios para cada
  aplicación
• La frecuencia que se espera que un usuario use la
  aplicación (número de sesiones/día de uso)
• Cuánto tiempo promedio durará una sesión de la
  aplicación (normalmente en segundos)
• Una estimación del número esperado de sesiones de
  usuario simultáneas para la aplicación

17
Patrones de uso
18
Caracterizar el Comportamiento

• Comportamiento de la aplicación
• Caracterizando el comportamiento de la
  aplicación, deseará considerar los tamaños de los
  datos que la aplicación estará procesando la
  frecuencia y duración de tiempo para los datos a
  ser transferidos por la red las características
  de flujo de tráfico para la aplicación,
  particularmente las direcciones de flujo (p.ej.,
  del cliente all servidor) y el grado de
  multicasting en las comunicaciones (uno-a-uno,
  uno-a-muchos, muchos-a-muchos).
• Modelos simples y complejos.

19
Desarrollo de Umbrales de Rendimiento

• Distinguiendo entre los servicios al mejor
  esfuerzo, especificado, y servicios de alto/bajo
  rendimiento, usaremos el criterio siguiente
• 1 Un umbral general puede usarse para separar
  requerimientos de rendimiento de bajo rendimiento
  y alto rendimiento.
• 2 Un umbral de ambiente-específico puede usarse
  para separar requerimientos de rendimiento en
  bajo rendimiento y alto rendimiento.
• 3 Los servicios especificados tendrán límites o
  garantías limitadas.

20
Requerimientos de Confiabilidad

• La medida más común de confiabilidad está en los
  términos de disponibilidad, como porcentaje de
  tiempo en servicio o porcentaje de tiempo fuera
  de servicio. Por ejemplo, un requerimiento para
  la propuesta de un usuario/cliente potencial
  final puede establecer un tiempo de servicio
  garantizado de 99.99, pero que realmente
  significa?

21
Requerimientos de Confiabilidad

• Disponibilidad
• Para un sistema que da servicio todo el día,
  siete días a la semana a sus clientes, la
  disponibilidad puede pensarse como el tiempo en
  servicio o fuera de servicio en porcentaje por
  semana, mes, o por año, basado en la cantidad
  total de tiempo por ese periodo.

22
Medición de Disponibilidad

• Cómo puede medirse la disponibilidad? Esta
  pregunta puede hacerse por lo menos en dos
  partes dónde debe medirse la disponibilidad, y
  qué métrica de servicio puede usarse para
  medirlo? Donde la disponibilidad debe medirse
  depende de que el diseñador o el administrador
  está tratando de lograr.

23
Disponibilidad medida selectivamente entre redes
24
Disponibilidad
Testbeds
Mayoría sistemas comerciales
Sistemas de Misión Crítica
Sistemas de Tiempo Real
Systemas de muy alta disponibilidad
25
Tiempo de Reestablecimiento

• MTBF/MTBSO y MTTR son tiempos promedios
• MTBF y MTBSO estiman la frecuencia de paros del
  sistema. Por ejemplo, un MTBF/MTBSO de 4400 horas
  (o 2.64E5 minutos) establece que las fallas en el
  sistema son esperadas aproximadamente cada 6
  meses (180 días).
• MTTR da una estimación de cuánto tiempo los paros
  del sistema pueden durar. Por ejemplo, un MTTR de
  60 minutos puede ser esperado si existe
  experiencia disponible en sitio, un MTTR de 4
  horas (240 minutos) puede esperarse si la
  ubicación es remota y el acceso de discado al
  sistema no está disponible.

26
Disponibilidad con MTBF/MTBSO y MTTR
27
Razones de Error y Pérdida

• Las pérdidas pueden medirse en la capa de enlace
  o de la red, y se informa como un porcentaje de
  tráfico disponible en la red. Así, nosotros
  podríamos establecer umbrales de pérdidas de
  celdas, frames, o paquetes y periodos de tiempo,
  como en la Tabla.

28
Umbrales para la confiabilidad

• Evalúe los requerimientos de disponibilidad de
  cada una de las aplicaciones que se usarán en su
  ambiente, de las discusiones con usuarios de las
  aplicaciones o de la documentación para cada
  aplicación
• Determine los umbrales de bajo-rendimiento/alto-re
  ndimiento
• Estime la disponibilidad basada en las rutas
  probables extremo-a-extremo que las aplicaciones
  usarán, y qué equipo y servicios existen o pueden
  estar en esas rutas.

29
Umbrales de referencia general para
Requerimientos de Usuario
30
Para Disponibilidad Las estimaciones del umbral
general son

• Confiabilidad de Testbed o Prototipo
  (disponibilidad) menos de 95
• Confiabilidad de bajo-rendimiento
  (disponibilidad) menos de 99.9
• Confiabilidad de alto-rendimiento
  (disponibilidad) mayor que o iguala a 99.9
• (Nota Éstos umbrales de disponibilidad son
  medidos mensualmente.)

31
Para el Reestablecimiento, medido como MTBF/MTBSO
y MTTR, las estimaciones de umbral general son

• Confiabilidad de bajo-rendimiento
  (reestablecimiento) MTTR mayor que 2 horas o un
  MTBF/MTBSO menos de 8000 horas
• Confiabilidad de alto rendimiento
  (reestablecimiento) MTTR menor de o igual a 2
  horas y MTBF/MTBSO mayor que o iguala a 8000
  horas
• (Nota Estos umbrales de reestabecimiento se
  escogen para proveer un MTTR razonable. Si un
  MTTR más pequeño es escogido, entonces el MTBF
  /MTBSO será correspondientemente más bajo.)

32
Razón de pérdida de información de
extremo-a-extremo ó razón de retransmisión

• Bajo-rendimiento (razón de pérdida) Pérdidas de
  paquete IP de
• 25 por lt 2 horas/mes
• 10 lt pérdida del paquete lt 25 por lt 2 horas/mes
• 1 lt pérdida del paquete lt 10 por lt 5 horas/mes
• lt 1 por el resto del mes

33
Requerimientos de Retardo
H
Data
Aplicación
Network
Red
Componentes

• Retardo de Interacción
• Tiempo de Respuesta Humano
• Retardo de propagación de la red

Host
34
Retardo de Interacción (INTD)

• estima cuánto tiempo un usuario está deseoso
  esperar por una contestación del sistema durante
  una sesión interactiva.
• Los retardos de la interacción pueden ir de unos
  pocos segundos a un minuto o más. En general, un
  rango útil es 10 a 30 segundos.

35
Tiempo de Respuesta Humano (HRT)

• estima el límite de tiempo cuando los usuarios
  empiezan a percibir retardo en el sistema.
• Cuando el tiempo de respuesta del sistema está
  debajo del HRT, los usuarios generalmente no
  perciben retardo en el sistema.
• Sobre el HRT, los usuarios notarán el retardo del
  sistema y puede llegar a frustrarse.
• Una estimación buena del HRT es aproximadamente
  100 ms.

36
Tiempo de Respuesta Humano (HRT)

• HRT es importante para las aplicaciones muy
  interactivas, donde los tiempos de espera no
  pueden o no deberían ser percibidos por el
  usuario.
• Éste normalmente es el caso cuando la aplicación
  apoya un ambiente interactivo para el usuario,
  como en visualización, realidad virtual, y las
  aplicaciones colaborativas, pero también puede
  aplicarse a las aplicaciones donde el retardo del
  sistema más allá de HRT produce pérdida de
  productividad.

37
Retardo de propagación de red

• Estima el retardo de la propagación de la señal
  en la red.
• Esto proporciona un límite inferior a los
  retardos de extremo-a-extremo y de ida y vuelta
  de la red y del sistema.
• El retardo de la propagación es dependiente en la
  distancia y tecnología.
• Es útil como un límite inferior de retardo,
  porque nos dice cuando una aplicación no puede
  trabajar bien por la red, cuando sus
  requerimientos de retardos son más severos que el
  retardo de la propagación por la red.

38
Estimación de retardos para requerimientos de
usuarios
39
Distinción entre aplicaciones de Ráfaga y Volumen
40
Tiempo de realización de Tarea (TCT)

• El uso de INTD y HRT posiblemente es la manera
  más directa de distinguir entre las aplicaciones
  de ráfaga interactivo y las aplicaciones de
  volumen interactivo, pero a veces se necesita un
  análisis más detallado.
• Para aquellos tiempos, podemos definir un tiempo
  de realización de tarea (TCT) para la aplicación,
  donde una tarea es la cantidad de trabajo de
  tiempo que está siendo realizado por el sistema
  antes de requerir la interacción con el usuario.
• TCT, medido en segundos, y el retardo de
  extremo-a-extremo RTT medido en milisegundos.

41
Tiempo de realización de Tarea (TCT)
Esta conducta es consistente con aplicaciones que
están procesando transacciones y cómputos
distribuidos, o son cliente-servidor.
42
Razón HRT a RTT

• La razón de HRT a RTT describe el grado de
  respuesta inherente en el sistema que es
  dependiente en la distancia que la aplicación
  está comunicando.
• Un RTT pequeño (relativo al HRT) significa que la
  distancia es suficientemente pequeña que la
  respuesta del sistema estaría dentro del tiempo
  de HRT, mientras que un RTT grande significa que
  el retardo impactará la respuesta del sistema.

43
Tiempos de RTT, TCT y HRT

• La respuesta del sistema también es en parte
  debida al TCT de la aplicación. La respuesta del
  sistema puede ser descrita por la razón de HRT,
  RTT, y TCT (donde HRT y RTT son medidos en
  milisegundos, y TCT es medido en segundos)

44
Respuesta del Sistema

• Respuesta del sistema HRT/TCT, cuando HRT/RTT
  gt 1
• Respuesta del sistema HRT/(RTTTCT), cuando
  HRT/RTT lt 1
• Respuesta del sistema lt 3 (volumen interactivo)
• Respuesta del sistema gt 3 (ráfaga interactivo)

45
Ejemplo

• una red que tiene un RTT (o tiempo de ping) de
  100 milisegundos (un valor aproximado para una
  red que cruza los Estados Unidos continentales) y
  un TCT de 10 segundos tendría una respuesta del
  sistema de HRT/RTT
  100ms/l00ms 1
• Respuesta del sistema 100ms/l0s 10
• Entonces, aplicación es Ráfaga Interactivo.

46
Burstiness

• Otra manera de distinguir entre las aplicaciones
  ráfaga interactivo y las aplicaciones volumen
  interactivo es con las razones de los datos.
• Burstiness se define como
• Burstiness PDR/SDR donde PDR y SDR son razón de
  datos peak y sostenido respectivamente

47
Retardo de extremo-a-extremo

• está compuesto de muchas fuentes de retardo,
  tales como propagación, encolamiento,
  transmisión, I/O, conmutación, y procesamiento.
• Verificar todas las rutas para encontrar los
  cuellos de botellas para hacer correr la
  aplicación.

48
Variación de Retardo

• La variación de retardo está acoplada con el
  retardo de alto rendimiento o especificado para
  dar un retardo global para aplicaciones que son
  sensible al tiempo de arrivo de la información.
• Algunos ejemplos de tales aplicaciones son
  aquellos que producen o usan video, audio, y
  información de telemetría. Para variaciones de
  retardo acoplada con retardo, cuando ninguna
  información está disponible sobre la variación de
  retardo, una regla buena es aproximadamente 1 a
  2 del retardo de extremo-a-extremo.
• Por ejemplo, una estimación para la variación de
  retardo en la ausencia de cualquier otra
  información, cuando el retardo de
  extremo-a-extremo de una aplicación es 40 ms, es
  aproximadamente 400 a 800 microsegundos

49
Requerimientos de capacidad

• Razón de Datos
• Tamaño de los datos

50
Ejemplos

• Podemos preguntarles a varios usuarios qué
  tamaños de archivos ellos esperan transferir, y
  cuánto tiempo ellos están deseosos esperar por la
  transferencia.
• Considere una aplicación de procesamiento de
  datos interactiva remota que se conecta a las
  tiendas de detalles y procesa información de los
  clientes, tal como entradas de tarjeta de
  crédito.
• Podemos basar una tarea como el proceso de la
  información de tarjeta de crédito de un solo
  cliente. Entonces, el TCT necesita estar en el
  orden de INTD discutida anteriormente
  aproximadamente de 30 segundos, aunque aquí puede
  esperarse que sea mucho más pequeño, digamos en
  el orden de 5 a 10 segundos, y los tamaños de los
  datos por cada tarea es bastante pequeño, en el
  orden de 100 a 1000 bytes.

51
Ejemplos

• Otro ejemplo es un ambiente de computación donde
  múltiples hosts están compartiendo el
  procesamiento para una tarea.
• En cada iteración de la tarea, los datos se
  transfieren entre los hosts.
• Aquí podemos saber la frecuencia del traslado de
  los datos, el tamaño de cada transferencia (qué
  también puede ser constante), y cuánto tiempo se
  requiere para procesar los datos (qué indicará
  cuánto tiempo una transferncia puede tomar).
• Un ambiente de computación multiprocesador
  compartido, se muestra en la siguiente figura.

52
Ejemplo de un ambiente de Cómputo con
Multiprocesadores
53
Región de Rendimiento con Umbrales Genéricos
54
Umbrales de Servicio de ambiente específico

• Los umbrales generales nos dan algunas
  estimaciones comúnes para las características de
  bajo y alto rendimiento.
• Tales umbrales son útiles cuando hay una falta de
  información sobre los usuarios y aplicaciones
  para la red a diseñár, pero a menudo el ambiente
  indica que umbrales de rendimiento deberían ser.
• Como con umbrales generales, la razón por
  desarrollar umbrales de ambiente específico es
  para determinar qué aplicaciones tienen
  características de alto rendimiento.
• Es probable que estas aplicaciones de alto
  rendimiento son lo que nosotros diseñaremos,
  junto con esas aplicaciones que tienen
  características especificas.

55
Comparando Características de la Aplicación

• Cuando podemos agrupar características de la
  aplicación, entonces una comparación puede
  hacerse a menudo para determinar donde el umbral
  puede aplicarse.
• Considere un gráfico de características de
  retardo para varias aplicaciones, A a través de
  M, para un ambiente particular, como se muestra
  en la figura 3-13.
• En este diagrama, se agrupan características de
  retardo en dos áreas.
• Podemos usar esta información para poner un
  umbral de ambiente específico a un retardo de
  aproximadamente X milisegundos.
• Esas aplicaciones que tienen una característica
  de retardo de menos de X milisegundos son
  consideradas de alto rendimiento para este
  ambiente.

56
Características de Retardo para una muestra de
aplicaciones
57
Servicios Deterministicos

• Los servicios deterministicos tienen
  características de rendimiento más específicos
  que el servicio al mejor esfuerzo que hemos
  estado discutiendo.
• En la mayoría de los casos, tendremos una buena
  estimación de éstos características de
  rendimiento, aunque no podremos garantizar
  rendimiento.
• Usaremos límites para aproximar donde están los
  niveles de bajo y alto rendimiento, los cuales se
  usarán en el proceso del diseño mas tarde en este
  libro para planificar la capacidad y la
  especificación de flujo.

58
Servicios garantizados

• Los servicios garantizados son un paso más allá
  de los servicios deterministicos, en que hay
  algún mecanismo para forzar al servicio a la
  aplicación o usuario. Así para desarrollar los
  requerimientos para los servicios garantizados,
  necesitamos tener características de rendimiento
  bien definidas.
• En la siguiente figura, el rendimiento de una
  aplicación se acerca al límite del servicio
  (garantizado). Ninguna acción se toma hasta que
  la aplicación excede su garantía, donde ocurre la
  vigilancia.
• Al elemento de la red donde ocurre la vigilancia,
  esto puede tomar la forma de marcar el
  paquete/frame/celda para que los elementos de red
  de flujo hacia abajo asuman alguna acción, o
  dejando caer el frame/paquete/celda en ese
  elemento de la red.
• Vigilar es a menudo útil para proteger el flujo
  de tráfico que fluye hacia abajo que excede su
  límite de servicio y intenta usar más recursos de
  la red que el contratado.

59
Vigilancia de rendimiento de un flujo
60
Servicios garantizados

• Se desarrollan garantías de servicio en una forma
  similar para servir los límites, excepto que se
  declara la necesidad de pedir una garantía
  explícitamente.
• En el ejemplo de asignación de recursos arriba,
  declaramos que la meta de confiabilidad era
  99.99, pero que debemos reunir una confiabilidad
  de por lo menos 99.97.
• Este límite más bajo para confiabilidad podría
  declararse como una garantía de servicio que
  significaría que después en el proceso del diseño
  lo consideraríamos como los mecanismos para
  proporcionar y vigilar ese servicio en el
  sistema.

61

• En la figura siguiente, los umbrales de servicio,
  límites, y garantías son ahora todos aplicados al
  sobre de rendimiento de servicio.
• En esta figura, las regiones de bajo y alto
  rendimiento están separadas por los umbrales
  generales D, M, y X, mientras un retardo de
  ambiente-específico, C, existe dentro de la
  región de bajo-rendimiento. Se muestran límites
  de servicio y garantías aquí en la región alto
  rendimiento, en varias situaciones en el sobre.

62
Sobre de Rendimiento Completamente Desarrollado
63
Aplicación de Telemetría

• Primero consideremos un ambiente de aplicación de
  telemetría, como es mostrado en la figura.

64
Aplicación de Telemetría

• En un análisis de este ambiente, hemos
  determinado (de las discusiones con los usuarios
  finales y diseñadores de la aplicación) que para
  que esta aplicación sea útil, los datos deben ser
  recibidos por la computadora de comando guiado
  dentro de 20 ms después de ser generados del
  helicóptero.
• También sabemos que el controlador actuará
  recíprocamente con el helicóptero basado en la
  entrada de flujo de telemetría, y que esto será
  ligado por el HRT para la aplicación (100 ms). De
  esta información, podemos limitar el retardo del
  flujo de telemetría, como es mostrado en la
  siguiente figura.

65
Limites de Retardo para el ejemplo de Telemetría
66
Consolidando la Computación
67
Consolidando la Computación

• La aplicación primaria en este ambiente es un
  asignador de recursos de computación, una
  aplicación que chequea los recursos dentro del
  sistema y asigna trabajos de computo a cada uno
  de los servidores de computación, basada en los
  requerimientos del trabajo.
• La asignación se hace rápidamente, en el orden de
  250 ms, y el estado de cada servidor de
  computación está constantemente verificándose.
• Antes de la consolidación, la confiabilidad de
  los servidores de computación a sus usuarios
  estaban sobre 99.97, mientras la meta de
  fiabilidad era sólo de 99.95.
• Para el ambiente consolidado, ellos quieren
  esforzarse para un grado mejor de confiabilidad y
  esperan lograr 99.99, pero aceptará un grado más
  bajo de confiabilidad, aunque no debajo de la
  confiabilidad real del sistema anterior (99.97).
  

68
Consolidando la Computación

• Aquí tenemos un límite de confiabilidad de alto
  rendimiento para diseñar hacia (99.99), y un
  límite del bajo-rendimiento que debe ser
  mantenido (99.97).
• Este límite más bajo posiblemente debe ser
  considerado como una garantía de servicio, pero
  aquí nosotros lo trataremos como un límite
  deterministico.
• Se muestran los límites en la confiabilidad para
  esta aplicación de asignación de recursos en la
  figura siguiente.

69
Límites de Confiabilidad para Aplicaciones de
Asignación de Recursos
70
Sobre de Rendimiento de Aplicación de Servicios

• Pueden aplicarse los límites deterministicos para
  todas las características de rendimiento a un
  sobre de rendimiento para la aplicación.
• Por ejemplo, si nosotros tenemos una aplicación
  que requiere el siguiente rendimiento
  especificado
• la confiabilidad, 99.8
• la capacidad, entre 14 y 20 Mb/s
• y retardo, no mayor que 80 ms, podemos aplicarlos
  como es mostrado en la siguiente figura.

71
Sobre de Rendimiento con Servicio Especificado
72
Distinguiendo entre los Niveles de Rendimiento de
Servicio

• tenemos las descripciones para varios niveles de
  servicio (rendimiento y función), como servicios
  al mejor esfuerzo, bajo rendimiento, alto
  rendimiento, y servicios especificados.
• Hemos tocado aplicaciones como misión-crítica,
  tiempo real, y razón controlada para
  distinguirlos de los servicios específicos
  necesitados, y también hemos desarrollado
  umbrales generales y de ambiente específico para
  separar los requerimientos de rendimiento en bajo
  y alto rendimiento para su ambiente del diseño.
• Ahora, examinaremos algunas pautas para ayudarle
  a usar estos conceptos juntos para distinguir
  entre los niveles de rendimiento de servicio para
  sus diseños.

73
Pautas en la Distinción de Servicios

• Usted debe usar estos pasos cuando usted quiere
  ver, en parte o en conjunto, modificando su
  secuencia para encajar mejor su metodología de
  análisis y ambiente de diseño.
• Para que usted aplique estos pasos, usted
  necesita tener un listado de las aplicaciones que
  probablemente se usarán en esta red, junto con
  cualquiera información de rendimiento que usted
  puede recoger, derivar, o estimar.
• Estos pasos van del requerimiento más específico
  con los requerimientos de aplicaciones a el más
  específico, de talmodo que el último paso sea el
  valor por defecto cuando ninguno de los otros
  pasos se aplican.

74
Pautas en la Distinción de Servicios

• 1. El primer paso es determinar si cualquiera de
  las aplicaciones tienen requerimientos obvios
  para especificar (deterministico o garantizado)
  el rendimiento del sistema.
• Cuando una aplicación tiene requerimientos para
  el rendimiento especificado, la aplicación y sus
  requerimientos son nombrados como especificados.

75
Pautas en la Distinción de Servicios

• 2. El segundo paso es listar las aplicaciones.
  Cuándo no se identifican aplicaciones que tengan
  requerimientos especificados, pueden
  identificarse como de misión-crítica, tiempo
  real, o razón controlada?
• En ese caso, pueden tener requerimientos
  especificado de rendimiento, aun cuando ellos no
  se reconocieron en el primer paso.

76
Pautas en la Distinción de Servicios

• 3. El tercer paso es aplicar grupos de
  aplicaciones a las aplicaciones. Para esas
  aplicaciones que no tienen requerimientos
  especificados obvios, y no puede listarse como
  misión-crítica, tiempo real, o razón controlada,
  evaluar si ellos pueden agruparse como de
  comando/telemetría visualización computo
  distribuído acceso de Web, desarrollo, y uso
  transporte de datos de volumen el teleservicios
  o aplicaciones de OAM.
• Es probable que esas aplicaciones que no pueden
  ser descritas por Pasos l a través de 3 sean
  aplicaciones al mejor esfuerzo.