Voz : Telefonía IP/Voice por IP (VoIP)

Control de Admisión de llamadas VoIP

29 Agosto 2008 - Traducción manual
Otras Versiones: PDFpdf | Inglés (20 Julio 2001) | Comentarios


Contenidos

Control de admisión de llamadas VoIP
Información general sobre el control de admisión de llamadas
Mecanismos locales de CAC
Mecanismos de CAC basados en medidas
Mecanismos de CAC basados en recursos
Cálculo de recursos frente a reserva de recursos
Indicación de disponibilidad de recursos
Ancho de banda de zona de control de acceso
Protocolo de reserva de recursos
Cómo aplicar CAC a la red

Control de admisión de llamadas VoIP


Número de la versión  Fecha  Notas 

1.1

Julio de 2001

La primera vez que se publicó este documento.

1.2

Agosto 2001

Cambios menores.

El control de admisión de llamadas (CAC, Call Admission Control) es un concepto que sólo se aplica al tráfico de voz, no al de datos. Si una afluencia de tráfico de datos realiza suscripciones en exceso en un enlace concreto de la red, las colas, la memoria intermedia y las decisiones de pérdida de paquetes resolverán la sobrecarga. El tráfico adicional se retrasará hasta que la interfaz vuelva a estar disponible para el envío del tráfico; o bien, si el tráfico se pierde, el protocolo o el usuario final inicia un tiempo de espera y solicita que se retransmita la información.

La sobrecarga de red no puede resolverse de esta manera cuando el tráfico en tiempo real, sensible tanto a la latencia como a la pérdida de paquetes, está presente y sin hacer peligrar la calidad del servicio (QoS, Quality of Service) que esperan los usuarios de ese tráfico. En el caso del tráfico sensible a los retrasos y en tiempo real, como la voz, es mejor denegar el acceso a la red en condiciones de sobrecarga que permitir que el tráfico de la red se interrumpa o se retrase con lo que la calidad del servicio será intermitente y se verá perjudicada. El resultado será la insatisfacción del cliente.

Por lo tanto, el CAC es una decisión informada y determinante que se toma antes de establecer una llamada de voz y se basa en que los recursos de red necesarios estén disponibles para ofrecer una calidad de servicio adecuada para la nueva llamada. El objetivo de este documento es ofrecer información general sobre el CAC, describir los diferentes mecanismos de CAC y tratar cómo se puede aplicar mejor a redes concretas.

Las personas a las que va dirigido este documento son usuarios de nivel 3 (competente), 4 (avanzado) y 5 (experto) de Cisco. Está dirigido principalmente a administradores de redes y equipos de operaciones que trabajen para proveedores de servicio que ofrecen servicios de VoIP. Este documento contiene las siguientes secciones:

Información general del control de admisión de llamadas

En el software Cisco IOS ya existen varios mecanismos de calidad del servicio distintos al CAC que sirven para diseñar y configurar redes de paquete que ofrezcan la latencia baja y la garantía de entrega necesarias para el tráfico de voz. Entre estos mecanismos se incluyen herramientas como la colocación en colas, control de tráfico, modelado de tráfico, marcación de paquetes, fragmentación y entrelazado. Estos mecanismos se diferencian del CAC en los siguientes aspectos principales:

  • Están diseñados para proteger el tráfico de voz del de datos que compiten por los mismos recursos de red.
  • Están diseñados para tratar con tráfico que ya está presente en la red.

Los mecanismos de CAC amplían las funciones del conjunto de herramientas de calidad del servicio (QoS) para evitar que el tráfico de voz se vea afectado de forma negativa por otro tráfico de voz y para mantener el exceso de tráfico fuera de la red. En la figura 1 se muestra por qué es necesario el CAC. Si el enlace de acceso WAN entre los PBX cuenta con el ancho de banda necesario para llevar sólo dos llamadas de VoIP, el Soportar una tercera hará que la calidad de la voz de las tres llamadas disminuya.


Figura 1   Red de VoIP sin CAC


La razón de esta disminución de calidad es que los mecanismos de cola ofrecen control de tráfico (pero no de CAC), lo que significa que si se reciben paquetes que exceden la velocidad permitida o configurada, se eliminarán al llegar a la cola. Los mecanismos de cola no cuentan con la capacidad para distinguir qué paquetes IP pertenecen a qué llamada de voz, de manera que cualquier paquete que supere la velocidad de llegada especificada en un periodo de tiempo concreto se eliminará. Por lo tanto, las tres llamadas sufrirán pérdida de paquetes, algo que los usuarios finales percibirán como cortes.

Este problema es fácil de resolver para los mecanismos de transporte de voz de capa 2 (VoFR y VoATM), pero es tremendamente molesto para las aplicaciones de VoIP, mucho más utilizadas y atractivas.

Alternativas de reenrutamiento de llamadas

En la figura 2 se muestra el punto en el que la puerta de enlace saliente toma una decisión de CAC al indicar que los recursos de red son insuficientes para procesar una llamada.


Figura 2   Red de VoIP con CAC


Después de rechazar la llamada, la puerta de enlace de origen debe encontrar otra forma de gestionar la llamada. Existen varias posibilidades, la mayoría de las cuales dependen de la configuración de la puerta de enlace. Si no hay una configuración especificada, la puerta de enlace saliente dará un tono de reorden a la parte que llama. Al tono de reorden se lo conoce como fast-busy (ocupado rápido) en Norteamérica, overflow tone (tono de desbordamiento) o equipment busy (equipo ocupado) en otras partes del mundo. Con frecuencia, los switches PSTN o los PBX interceptan este tono con un anuncio que indica que todos los circuitos están ocupados y que se vuelva a llamar más tarde.

Se puede configurar la puerta de enlace saliente para las siguientes situaciones de reenrutamiento:

  • La llamada puede volver a enrutarse mediante una ruta de red de paquete alternativa, si existe dicha ruta, lo que exige la configuración de un segundo par de marcado VoIP con un orden de preferencia inferior que el elegido en un primer momento.
  • La llamada puede volver a enrutarse mediante una ruta de red TDM alternativa, si dicha ruta existe, lo que exige la configuración de un par de marcado POTS y una interfaz TDM física para PSTN u otro PBX.
  • Se podrá devolver la llamada al switch TDM original para sacar el máximo partido a una de las siguientes funciones de reenrutamiento.
    • Si la conexión entre el switch de origen y la puerta de enlace saliente es un troncal de sistemas de señalización de canales comunes (CCS, Common Channel Signaling) como, por ejemplo, QSIG, PRI o BRI, la llamada podrá rechazarse y se le asignará un código de causa. El switch de origen cerrará el troncal y reanudará la gestión de la llamada.
    • Si la conexión entre el switch de origen y la puerta de enlace saliente es un troncal analógico o de señalización asociada de canales (CAS, Channel-Associated Signaling) como, por ejemplo, E&M, T1 CAS o T1 FGD, se deberá devolver la llamada al switch (usando un segundo troncal en la misma interfaz).

Mecanismos de CAC

Como se han tratado muchos aspectos interesantes del CAC en las redes de paquetes, se han puesto de relieve varias soluciones. Ninguna de ellas resuelve el problema por completo pero todas son útiles para afrontar un aspecto concreto del CAC. A diferencia de las redes basadas en circuitos (que reservan un intervalo de tiempo DS0 gratuito en cada tramo de la ruta que tomará la llamada), determinar si una red de paquete cuenta con recursos para realizar una llamada de voz no es una tarea sencilla. Esta sección incluye a su vez las siguientes subsecciones:

Categorías de los mecanismos de CAC

El resto de este documento trata sobre diez mecanismos de CAC distintos disponibles en las versiones actuales del software Cisco IOS. Se agrupan en las siguientes tres categorías:

  • Mecanismos de CAC locales: estos mecanismos funcionan en la puerta de enlace saliente. La decisión del CAC se basa en información de nodos como el estado del enlace LAN o WAN saliente. Si el enlace de red del paquete local está inactivo, no sirve de nada ejecutar la lógica de decisiones complejas según el estado del resto de la red ya que no se puede llegar a ella. Los mecanismos locales incluyen elementos de configuración para no permitir más de un número concreto de llamadas. Por ejemplo, si el diseñador de red ya sabe que no podrán pasar más de cinco llamadas por el enlace WAN saliente debido a las limitaciones del ancho de banda, parece lógico que debería ser posible configurar el nodo local para que no permita más de esas cinco llamadas.
  • Mecanismos de CAC basados en medidas: las técnicas de CAC basadas en medidas examinan la red de paquete para medir su estado con el objeto de determinar si se debe permitir una nueva llamada. Medir el estado de la red supone enviar sondas a la dirección IP de destino (normalmente la puerta de enlace o el control de acceso de terminación) que volverán a la puerta de enlace saliente con información de medición sobre las condiciones que ha encontrado la sonda al atravesar la red hasta el destino. Por lo general, la información sobre las pérdidas o los retrasos es la más interesante para la voz.
  • Mecanismos de CAC basados en recursos: existen dos tipos de mecanismos basados en recursos, los que calculan los recursos necesarios y/o disponibles y los que reservan recursos para la llamada. Los recursos en cuestión incluyen el ancho de banda del enlace, intervalos de tiempo de DSP y DS0 en los troncales TDM de conexión, potencia de la CPU y memoria. Se podrían restringir algunos de estos recursos en uno o varios de los nodos que la llamada atravesará hasta su destino.

Existen dos categorías adicionales de funciones del CAC, pero no tratan las cuestiones de diseño de la red ni de infraestructura y, por lo tanto, no se explicarán en este documento. Estas dos categorías del CAC (seguridad y usuario) se centran en cambio en la política de si se permite a la llamada o al usuario final usar la red de la siguiente manera:

  • Seguridad: ¿se trata de un dispositivo legítimo o puerta de enlace en la red? Existen mecanismos de autenticación, incluidos los protocolos como el H.235, que cubren este aspecto del CAC.
  • Usuario: ¿está este usuario final autorizado para usar la red? Hay métodos de verificación de CLID/ANI y PIN, que se realizan normalmente mediante la respuesta de voz interactiva (IVR, Interactive Voice Response) para comprobar la autorización.

CAC basado en medidas frente a CAC basado en recursos

Hay poca superposición entre los mecanismos locales de CAC y los que examinan el resto de la red para determinar las condiciones no locales. Por lo tanto, es fácil de entender por qué los distintos mecanismos locales y de "nube" son útiles. No obstante, hay una superposición considerable entre las técnicas de medición y las de reserva de recursos de los dos mecanismos de CAC directos de nube. Por esta razón se ha generado un debate sobre cuál es el mejor método.

En la tabla 1 se comparan las ventajas y los inconvenientes de los mecanismos de CAC basados en las medidas y los basados en los recursos. Gracias a esta información, podrá determinar el método que mejor se ajuste a su red.

Tabla 1   Comparación de las características de los mecanismos de CAC basados en medidas y los basados en la reserva de recursos

Criterios  Técnicas basadas en medidas  Técnicas basadas en la reserva de recursos 

Topología de red

Independiente de topología.

La sonda viaja hasta la dirección IP de destino. No tiene información de nodos, saltos ni disponibilidad de ancho de banda de los enlaces individuales.

Depende de la topología.

Se tiene en cuenta la disponibilidad de ancho de banda en nodos y enlaces.

Transparencia de la estructura básica

Transparente.

Las sondas son paquetes IP que pueden enviarse por cualquier red, incluidas las estructuras básicas de SP e Internet.

Para que las técnicas de reserva sean realmente el método de extremo a extremo que pretenden ser, se debe configurar la característica en cada interfaz a lo largo de la ruta, lo que quiere decir que el cliente posee la estructura básica de WAN y que todos los nodos ejecutan el código que implementa la característica. En algunos casos, poseer la estructura básica completa no es práctico por lo que se podrían contemplar topologías híbridas en las que se vería comprometida de alguna manera la naturaleza de integral del método.

Retraso posterior al marcado

El aumento en el retraso posterior al marcado sólo existe para la primera llamada. La información del destino se almacena en caché después de eso y se envía una sonda periódica al destino IP. Las llamadas posteriores se permiten o deniegan basadas en la información más reciente almacenada en caché.

El aumento en el retraso posterior al marcado existe para cada llamada, ya que la reserva del protocolo de reserva de recursos (RSVP, Resource Reservation Protocol) debe establecerse antes de que se pueda completar la configuración de la llamada.

Paridad de la industria

Algunos proveedores cuentan con funciones de CAC parecidas a "ping". Para aquellos clientes que están familiarizados con esta operación, las técnicas basadas en medidas pueden ser muy adecuadas.

Precisión de CAC

La velocidad periódica de muestreo de las sondas pueden Soportar llamadas potencialmente cuando el ancho de banda es insuficiente. Las técnicas basadas en medidas actúan bien en redes en las que las fluctuaciones de tráfico son graduales.

Cuando se implementan en todos los nodos de la ruta, RSVP garantiza el ancho de banda a la llamada en toda la ruta y durante toda la llamada. Esta es la única técnica que consigue este nivel de precisión.

Protección de la calidad del servicio de la voz después de la admisión

Antes de Soportar la llamada, la decisión de CAC se basa en las estadísticas de tráfico de la sonda. Después de la admisión, la calidad de la llamada está determinada por la efectividad de otros mecanismos de calidad de servicio en la red.

Se establece una reserva por llamada antes de admitirla. La calidad de la llamada no se verá, por lo tanto, afectada por los cambios en las condiciones de tráfico de la red.

Tara de tráfico de red

Tara de tráfico de sondas periódicas en un número almacenado en caché de destinos IP. Tanto el tamaño de intervalo como de caché pueden ser controlados por la configuración.

Tara de tráfico de mensajería de RSVP para cada llamada.

Escalabilidad

El envío de sondas a miles de destinos IP individuales puede no ser práctico en una red de gran tamaño. Sin embargo, las sondas pueden enviarse a los dispositivos de borde WAN que actuarán de proxy en nombre de muchos más destinos en una red de oficinas centrales de banda ancha alta detrás del borde. De esta forma se ofrece mayor escalabilidad porque es mucho más probable que la WAN esté sobrecargada que la LAN de las oficinas centrales.

La reserva de flujo individual es importante en los enlaces de banda ancha pequeña alrededor del borde de la red. Sin embargo, es posible que las reservas individuales por flujo de llamada no tengan sentido en enlaces de banda ancha grande en la estructura básica como en un OC-12. Las topologías de red híbridas pueden resolver esta necesidad y las herramientas RSVP que se van a describir posteriormente ofrecerán más escalabilidad.

Resumen de las características de CAC

En la tabla 2 se resumen los diez mecanismos de CAC de voz distintos que se tratarán en detalle en este documento. También se indicará la primera versión de Cisco IOS en la que apareció la característica.

Tabla 2   Características de CAC

Tipo  Característica de CAC  Versión del SW 

Local

 

 

 

Limitación física de DS0

Independiente del SW

 

Conexiones máximas en el par de marcado

11.3

 

Ancho de banda de voz VoFR

12.0.(4)T

 

Condicionamiento troncal

12.1.(2)T

 

Estado ocupado de voz local (LVBO, Local Voice Busyout)

12.1.(2)T

Basado en medidas

 

 

 

Estado ocupado de voz avanzado (AVBO, Advanced Voice Busyout)

12.1.(3)T

 

Repliegue de PSTN

12.1.(3)T

Basado en recursos

 

 

  • Cálculo de recursos

 

 

 

Indicación de disponibilidad de recursos

12.0.(5)T (AS5300)
12.1.(3)T (2600/3600)

 

Ancho de banda de zona de control de acceso

11.(3) (zona local)
12.1.(5)T (interzona)

  • Reserva de recursos

 

 

 

Protocolo de reserva de recursos

12.1.(5)T

Aplicabilidad de la tecnología de los mecanismos de CAC

Al tener en cuenta las distintas características disponibles para resolver un requisito de diseño en concreto como el CAC, es útil eliminar inmediatamente los mecanismos que no son aplicables a la tecnología de red que esté considerando. En la tabla 3 se resumen las tecnologías de voz a las que se aplicarán las distintas características de CAC.

Tabla 3   Tecnologías de voz compatibles con las características de CAC

Función  VoIP con H.323  VoIP con SIP  VoIP con MGCP  VoFR  VoATM  CM  H.323 Video 

Limitación física de DS0

No

No

Conexiones máximas

No

No

Ancho de banda de la voz

No

No

No

No

No

No

Condicionamiento troncal

No

No

Estado ocupado de voz local

No

No

Estado ocupado de voz avanzado

No

No

No

No

Repliegue de PSTN

No

No

No

No

Indicación de disponibilidad de recursos

No

No

No

No

No

No1

Ancho de banda de zona de control de acceso

No

No

No

No

Protocolo de reserva de recursos

No

No

No

No

No

No

Tenga en cuenta que las funciones de RAI de H.323 sí se aplican de hecho a las aplicaciones de video de H.323. Sin embargo, en la tabla aparece como "No" porque las puertas de enlace que estamos considerando en este documento son puertas de enlace de voz de Cisco IOS y no generan indicaciones RAI para el tráfico de video.

Determinación del ancho de banda de la voz

Para implementar correctamente los mecanismos de CAC en la red de voz, debe saber exactamente la cantidad necesaria de ancho de banda para cada llamada de manera que pueda tener una red acorde con el número de llamadas necesarias y ajustar los mecanismos de CAC para rechazar las que superen ese número. A pesar de las cifras de banda ancha publicadas para cada códec, no hay una única respuesta para la cantidad de ancho de banda necesaria para una llamada. Hay otras características de la red, además del códec usado, que determinan los requisitos exactos de ancho de banda.

Aunque tratar de forma exhaustiva los cálculos de ancho de banda está más allá del objetivo de este documento, sí que merece la pena revisar algunas de las consideraciones que hay que recordar. En la interfaz física, el ancho de banda de voz utilizado por una única llamada de voz depende de los siguientes factores:

  • Tecnología de voz utilizada (VoIP, VoATM, VoFR)
  • Medios de capa 2 utilizados (Ethernet, serie/MLP, FR, ATM)
  • Códec utilizado
  • Técnicas de compresión de encabezado (sólo aplicable a VoIP)
  • Detección de actividad de voz (VAD, también conocida como "supresión de silencio")

En el caso de redes ATM, que utilizan celdas de longitud fija, debe tenerse en cuenta la tara de la carga útil de voz (paquete IP para VoIP sobre ATM o carga útil de códec para VoATM) que se ajuste a las celdas ATM.

En la tabla 4 se resumen las combinaciones de VoIP más comunes de los factores descritos y el ancho de banda resultante de la llamada.

Tabla 4   Requisitos de ancho de banda de VoIP

Códec  Ancho de banda de códec (kbps)  Longitud de muestra (ms)  Tamaño de muestra (Bytes)  Muestras por paquete  Tamaño de encabezado de IP (Bytes)  Tecnología de capa 2  Tamaño de encabezado de capa 2 (Bytes)  Ancho de banda necesario de llamada de voz (kbps) 

G.711

64

10

80

2

40

Ethernet

14

85,6

G.711

64

10

80

2

40

MLP/FR

6

82,4

G.711

64

10

80

2

2 (cRTP)

MLP/FR

6

67,2

G.729

8

10

10

2

40

Ethernet

14

29,6

G.729

8

10

10

2

40

MLP/FR

6

26,4

G.729

8

10

10

2

2 (cRTP)

MLP/FR

6

11,2

La fórmula utilizada para calcular el ancho de banda de cualquier combinación de factores es la siguiente:

Ancho de banda de voz = (carga útil + L3 + L2) * 8 * pps

Los componentes de la fórmula se corresponden con los siguientes valores:

  • Carga útil = carga útil en bytes generada por el códec
  • L3 = capa 3 y tara de encabezado de capa superior en bytes (0 para VoFR y VoATM)
  • L2 = tara de encabezado de capa de enlace en bytes
  • 8 = cantidad de bits por byte
  • pps= velocidad de paquetes por segundo generada por el códec

Las tecnologías de transporte de capa 2 cuentan con las siguientes taras de encabezado:

  • Ethernet: 14 bytes
  • PPP y MLP: 6 bytes
  • Retransmisión por frame (frame relay): 6 bytes
  • ATM (AAL5): 5 bytes (más eliminación de llenado de celda)
  • MLP sobre retransmisión por frame (frame relay): 14 bytes
  • MLP sobre ATM (AAL5): 5 bytes por cada celda ATM + 20 bytes para la encapsulación de MLP y AAL5 del paquete IP

A continuación, se muestran algunos ejemplos de cálculos de ancho de banda:

  • G.729 / VoIP / MLPPP / no cRTP / no VAD: (20 + 40 + 6) * 8 * 50 = 26,4 kbps
  • G.729 / MLPPP / cRTP / no VAD: (20 + 2 + 6) * 8 * 50 = 11,2 kbps
  • G.729 / VoIPovFR / no cRTP / no VAD: (20 + 40 + 6) * 8 * 50 = 26,4 kbps
  • G.729 / VoFR / no VAD: (20 + 6) * 8 * 50 = 10,4 kbps

Criterios de evaluación de los mecanismos de CAC

Puesto que se van a describir los métodos de CAC en lo que queda del documento, se evaluarán con respecto a varios factores y criterios que ayudarán a determinar el mejor mecanismo de CAC o el más apropiado para el diseño de red que estamos considerando.

En la tabla 5 se describen los criterios que se usarán para evaluar las distintas herramientas de CAC.

Tabla 5   Criterios de evaluación de las características de CAC

Criterios de evaluación  Descripción 

Compatible con VoX

Las tecnologías de voz a las que se aplicará el método. Algunos métodos se aplican a una tecnología mientras que otros se aplican a toda la placa.

Conexión troncal o telefonía IP

Trata sobre si el método se usa sólo entre las puertas de enlace de voz conectadas a la PSTN o al PBX o si también puede usarse con los puntos extremos del teléfono IP.

Plataformas y versiones

Las plataformas de Cisco IOS en las que la característica ya está disponible y la versión del software en la que se introdujo por primera vez.

Tipos de troncal PBX compatibles

Algunas características de CAC dependen del tipo de troncal PSTN o PBX utilizado en la conexión o actúan de manera diferente con los troncales de CCS que con los troncales de CAS.

Extremo a extremo, local o nube IP

El ámbito de visibilidad de la característica de CAC. Algunos mecanismos sólo funcionan de manera local en la puerta de enlace de origen, otros consideran la nube entre los nodos de origen y de destino, algunos tienen en cuenta la interfaz POTS de destino y otros funcionan de extremo a extremo.

Por llamada, interfaz o punto final (endpoint)

Los distintos mecanismos suponen distintos elementos de la red. Algunos métodos de CAC funcionan por llamada, otros por interfaz y algunos por punto final (endpoint) o destino IP.

Reconocimiento de topología

Trata sobre si el mecanismo de CAC tiene en cuenta la topología de la red y, por lo tanto, ofrece protección a los enlaces y nodos de la topología.

Garantías de calidad del servicio durante la llamada

Trata sobre si el mecanismo toma una decisión única antes de permitir la llamada o si también protege la calidad del servicio durante la llamada al reservar los recursos necesarios.

Retraso posterior al marcado

Trata sobre si el mecanismo impone un retraso posterior al marcado adicional porque necesita mensajería o procesamiento adicional durante la configuración de la llamada.

Tara de mensajería de red

Trata sobre si el método utiliza mensajería adicional que debe ofrecerse en la red para recopilar la información necesaria para la decisión de CAC.

Mecanismos locales de CAC

Los mecanismos locales son los mecanismos de CAC más simples de comprender e implementar. Funcionan en la puerta de enlace saliente y tienen en cuenta las condiciones locales del nodo. También tienden a tener menos tara de manera que si alguno de estos mecanismos ofrece la funcionalidad deseada, habrá pocas razones para implementar cualquiera de las características más complejas. Sin embargo, es probable que en una red de un tamaño razonable, la funcionalidad de CAC satisfactoria necesite más que el uso de un mecanismo local.

En esta sección se discutirán los siguientes cinco mecanismos locales de CAC:

Limitación física de DS0

La limitación física de DS0 no es una característica de software específica sino una metodología de diseño basada en las limitaciones físicas de las interfaces. Aunque resulta sencilla cuando se compara con alguna de las otras características, se trata, sin embargo, de un bloque de creación fundamental para muchas redes de clientes ya existentes.

Por ejemplo, si desea limitar la cantidad de llamadas del PBX original a la puerta de enlace saliente a cinco, configure o active sólo cinco intervalos de tiempo en el troncal T1 o E1 entre el switch y la puerta de enlace saliente. En la figura 3 se ilustra este principio:


Figura 3   Limitación física de DS0


Puesto que es local, este método de diseño de CAC ofrece una protección adecuada para el enlace WAN de salida desde la puerta de enlace saliente. Cuenta con las mismas limitaciones que otros mecanismos locales: no ofrece protección frente a la disponibilidad de ancho de banda en cualquier otro enlace de la red. Funciona bien en topologías sencillas de red radial y razonablemente bien en redes jerárquicas más complejas de varias capas por la sencilla razón de que la cantidad máxima de posibles llamadas (en el peor de los casos) en cualquier enlace de la estructura básica puede estimarse de manera precisa mediante un cálculo basado en la cantidad conocida de llamadas que pueden entrar en cada ubicación de extremo y en los patrones de tráfico de llamadas en horas punta entre ubicaciones.

Aunque este método de CAC funciona bien en aplicaciones de conexión troncal (de puerta de enlace a puerta de enlace), no funciona para la telefonía IP porque no hay una interfaz TDM física en la que se puedan restringir los intervalos de tiempo. Tal y como se muestra en la figura 4, cuando los dispositivos en los medios de LAN producen llamadas, la capacidad de ancho de banda de los medios físicos aventaja en gran medida la de la interfaz de salida WAN. Sin otras características de software en el punto de agrupamiento (normalmente el router de borde de WAN) para "preparar" la llegada de nuevas llamadas, no hay una manera física de mantener las nuevas llamadas fuera de la red.


Figura 4   Aplicaciones de telefonía IP


En resumen, restringir los DS0 físicos que entran en la red ofrece las siguientes ventajas:

  • No añade tara adicional de CPU o ancho de banda a la red.
  • Funciona bien para muchas aplicaciones de elusión de cargos por larga distancia.
  • En la actualidad es el mecanismo de CAC predominante implementado en las redes de elusión de cargos por larga distancia.
  • Protege el ancho de banda en el enlace WAN de salida del sitio local.
  • Puede ofrecer protección de predicción en la estructura básica según los patrones de tráfico en horas punta.

El método de CAC de limitación física de DS0 cuenta con las siguientes restricciones:

  • No funciona con aplicaciones de telefonía IP.
  • Está limitado a topologías relativamente sencillas.
  • No reacciona frente a errores de enlace o cambio en las condiciones de red.

En la tabla 6 se evalúa el mecanismo de limitación física de DS0 frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 6   Resumen del mecanismo de limitación física de DS0

Criterios de evaluación  Valor 

Compatible con VoX

Independiente de la tecnología VoX utilizada

Conexión troncal/Telefonía IP

Sólo aplicaciones de conexión troncal

Plataforma/Versión

Todas las puertas de enlace de voz y todas las versiones de Cisco IOS

Tipos de troncal PBX compatibles

Todos

Extremo a extremo/Local/nube IP

Local

Por llamada/interfaz/punto final (endpoint)

Por DS0/troncal (por llamada)

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Ninguna

Conexiones máximas

El mecanismo de CAC de conexiones máximas supone utilizar el comando de configuración del par de marcado max-conn en un par de marcado de la puerta de enlace saliente para restringir la cantidad de conexiones simultáneas (llamadas) que pueden estar activas en ese par en cualquier momento.

Esta herramienta es fácil de usar pero limitada en cuanto a los problemas de diseño de red que puede resolver. Puesto que se aplica por par de marcado, no es posible limitar la cantidad total de llamadas que la puerta de enlace saliente puede tener activas simultáneamente a menos que cuente con una cantidad limitada de pares de marcado y utilice el comando max-conn en cada uno.

Teniendo en cuenta esta limitación, el comando max-conn ofrece un método de CAC viable en al menos dos situaciones, tal y como se describe a continuación:

  • Para una cantidad relativamente pequeña de pares de marcado que dirigen las llamadas a un enlace WAN de salida, la suma de las declaraciones de pares de marcado max-conn ofrecerán la cantidad de llamadas que pueden estar activas simultáneamente en el enlace WAN.
  • Si el objetivo del diseño es limitar la cantidad máxima de llamadas entre sitios (en lugar de proteger el ancho de banda del enlace WAN de salida), el uso de esta característica será muy adecuado, siempre que los pares de marcado se estructuren de tal forma que cada sitio remoto tenga uno que dirija las llamadas a él.

En la figura 5 se muestra un ejemplo de este tipo de red: hay tres sitios remotos, cada uno con los primeros dígitos reconocibles en el plan de marcado. Por lo tanto, los pares de marcado VoIP salientes en las oficinas principales (HQ) coinciden con los sitios remotos uno a uno. La cantidad de llamadas a los sitios remotos 1, 2 y 3 se limitará a 4, 6 y 8 respectivamente. El enlace WAN de salida no podrá tener, por lo tanto, más de 18 llamadas activas a la vez. En esta configuración, la provisión de ancho de banda de este enlace para esa cantidad de llamadas sería prudente.


Figura 5   Conexiones máximas configuradas en el par de marcado


Las conexiones máximas también pueden usarse en el par de marcado POTS para limitar la cantidad de llamadas que pueden estar activas en un T1/E1 a un PBX/PSTN si lo que se desea es ofrecer todos los intervalos de tiempo en esa conexión pero limitar la cantidad de llamadas a un número inferior al número físico de intervalos de tiempo.

En el siguiente ejemplo de configuración, una llamada de VoIP que coincida con el comando dial-peer voice 800 voip tendrá todos sus paquetes de carga útil de voz definidos con una precedencia IP de 5, lo que significa que los tres bits más significativos del byte del tipo de servicio (ToS, Type of Service) IP están definidos en 101. El primer par de marcado se configura para recibir un máximo de 24 llamadas simultáneas. Las llamadas adicionales se enviarán a la PSTN mediante el segundo par de marcado.

dial-peer voice 800 voip
!Define que este grupo rotativo tiene primera prioridad.
preference 1
!Define la cantidad máxima de conexiones (control de admisión activo).
max-conn 24
 destination-pattern 83123... 
 ip precedence 5 
 session target ipv4:172.17.251.28 
!
dial-peer voice 600 pots
!Define que este grupo rotativo tiene segunda prioridad.
preference 2
 destination-pattern 83123...
direct-inward-dial
  port 0:D
!Añade el prefijo 99 delante del número llamante para avisar al PBX para desbordar a la PSTN.
prefix 9983123

Aunque esta característica es útil en muchas situaciones, tiene los siguientes inconvenientes:

  • A pesar de que ofrece protección para el enlace WAN de salida de la puerta de enlace de voz, proporciona poca o ninguna protección a los enlaces de la estructura básica de la red.
  • No funciona para las aplicaciones de telefonía IP que no utilizan pares de marcado.
  • Está limitado a topologías sencillas.
  • No reacciona a errores de enlace ni a cambios en las condiciones de red.

En la tabla 7 se evalúa el mecanismo de conexiones máximas frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 7   Resumen del mecanismo de conexiones máximas

Criterios de evaluación  Valor 

Compatible con VoX

Todos los VoX que utilizan pares de marcado

Conexión troncal/Telefonía IP

Sólo aplicaciones de conexión troncal

Plataforma/Versión

Todas las puertas de enlace de voz y todas las versiones de Cisco IOS

Tipos de troncal PBX compatibles

Todos

Extremo a extremo/Local/nube IP

Local

Por llamada/interfaz/punto final (endpoint)

Por par de marcado

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Ninguna

Ancho de banda de la voz

En las configuraciones de VoFR, se utiliza un comando de configuración de interfaz de frame-relay voice-bandwith en la clase de asociador de retransmisión por frame (frame relay) para asignar el ancho de banda a llamadas VoFR. Este método de asignación de banda ancha funciona de manera similar a la forma en que las características de prioridad IP RTP y cola de tiempo de latencia bajo (LLQ, Low Latency Queueing) reservan ancho de banda para flujos de tráfico generales. Sin embargo, el comando frame-relay voice-bandwidth también ofrece el CAC, algo que las características generales de cola no ofrecen.

El comando frame-relay voice-bandwidth puede ofrecer CAC porque VoFR es una tecnología de capa 2. Al mirar los encabezados de FRF.11 (voz) o FRF.3.1 (datos), el software Frame Relay puede determinar qué tramas son de voz y cuáles de datos. El software también sabe qué tramas pertenecen a la llamada de voz porque los campos posteriores en el encabezado llevan identificación de canal (CID, Channel Identification) e información de carga útil. Debido a que el comando frame-relay voice-bandwidth destina banda ancha para la voz, también puede denegar la siguiente llamada si esa llamada adicional provoca que se supere el ancho de banda total asignada a la voz.

Sólo se usa este método de CAC si VoFR es una tecnología viable para su red. También debe tenerse en cuenta que el valor predeterminado del tamaño de ancho de banda para voz sea 0 de manera que si no se especifica la reserva de ancho de banda, no se permitirá ninguna llamada de voz en el enlace WAN. No incluya tráfico de señalización en el ancho de banda que especifique con este comando, sólo el tráfico de carga útil de voz.

El siguiente ejemplo de configuración ofrece el CAC para VoFR al proporcionar 24 kbps, suficiente para las dos llamadas de G.729 a 10,4 kbps cada una.

interface Serial0/0
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!         
interface Serial0/0.1 point-to-point
  frame-relay interface-dlci 16   
  class vofr
!
map-class frame vofr
  frame cir 60000
  frame bc 600
  frame frag 80
  frame fair-queue
!24 kbps es suficiente para dos llamadas de G.729 a 10,4 kbps cada una.
  frame-relay voice-bandwidth 24000

En la tabla 9 se evalúa el mecanismo de ancho de banda de voz frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 8   Resumen del mecanismo de ancho de banda de voz

Criterios de evaluación  Valor 

Compatible con VoX

VoFR

Conexión troncal/Telefonía IP

Sólo aplicaciones de conexión troncal

Plataforma/Versión

Routers Cisco 2600, 3600, 3810 y 7200; versión 12.0(4)T de Cisco IOS

Tipos de troncal PBX compatibles

Todos

Extremo a extremo/Local/nube IP

Local

Por llamada/interfaz/punto final (endpoint)

Por llamada, por PVC

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Ninguna

Condicionamiento troncal

El condicionamiento troncal ofrece más funcionalidad que sólo el CAC, pero en este documento sólo trataremos los aspectos del CAC. Se puede usar en redes troncales de conexión (redes con conexiones de voz permanentes a través de la parte de VoX de la red) para supervisar el estado de la conexión de VoX y enviar una señal de ocupado del troncal al PBX original si la conexión de VoX falla.

Esta característica tiene un ámbito limitado porque sólo se aplica a redes troncales de conexión. Sin embargo, la mayoría de las características de CAC sólo se aplican a redes conmutadas.

La implementación del CAC en una configuración de troncal de conexión supone un problema ligeramente distinto de la implementación en redes conmutadas porque las conexiones de VoX entre las dos puertas de enlace son permanentes, tal y como se muestra en la figura 6. Por lo tanto, el ancho de banda ya está establecido y asignado y debe estar disponible ya que, de lo contrario, las conexiones del troncal de conexión no se establecerán adecuadamente.


Figura 6   Condicionamiento troncal


El único atributo del condicionamiento troncal comparado con otras características de CAC es que no sólo tiene visibilidad de la condición de extremo a extremo de la WAN sino también de la conexión de POTS en el lado de terminación de la red. En la figura 6, si alguno de los tramos A, B, C o D fallaran, la puerta de enlace saliente lo sabría y podría enviar una señal de ocupado del troncal al PBX de origen para activar el reenrutamiento en el origen. Esta información forma parte de los mensajes de las señales de mantenimiento que se generan en las configuraciones del troncal de conexión.

Podrá ajustar el patrón de bits exacto que se generará en el PBX de origen. Los bits ABCD pueden configurarse para indicaciones específicas de ocupado o de fuera de servicio (OOS, out-of-service) que el PBX de origen reconocerá y sobre el que actuará.

El condicionamiento troncal no es, por lo tanto, una característica de llamada por llamada, como lo son las características descritas hasta ahora. Se trata de una característica de señal de ocupado (o fuera de servicio) del troncal al PBX. Si se produce un error en la WAN, el troncal hacia el PBX se pondrá en fuera de servicio de manera que no se podrán hacer llamadas a través de ese troncal hasta que se recupere la conectividad de la WAN.

En la tabla 9 se evalúa el mecanismo de condicionamiento del troncal frente a los criterios de evaluación del CAC descritos anteriormente en este documento.

Tabla 9   Resumen del mecanismo de condicionamiento troncal

Criterios de evaluación  Valor 

Compatible con VoX

VoIP/H.323, VoFR, VoATM (sólo configuraciones del troncal de conexión)

Conexión troncal/Telefonía IP

Sólo aplicaciones de conexión troncal

Plataforma/Versión

Routers de las series Cisco 2600 y 3600 y concentradores de acceso múltiple Cisco MC3810; versión 12.1(3)T de Cisco IOS

Tipos de troncal PBX compatibles

Analógico y CAS

Extremo a extremo/Local/nube IP

Local

Por llamada/interfaz/punto final (endpoint)

Por interfaz de telefonía

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Ninguna, utiliza las señales de mantenimiento del troncal de conexión existentes

Estado ocupado de voz local

A algunos mecanismos de CAC se los denomina características de señal de ocupado troncal. El primero que hemos encontrado ha sido un condicionamiento troncal en la sección anterior. Esta característica sólo funciona en redes del troncal de conexión. Es necesario una funcionalidad similar para redes conmutadas y LVBO es la primera de las dos características que lo consigue.

LVBO permite poner completamente fuera de servicio una conexión troncal de PBX a la puerta de enlace asociada cuando se considere que las condiciones de la WAN no son adecuadas para llevar tráfico de voz. Esta técnica tiene las siguientes ventajas:

  • No se tendrán que rechazar las llamadas de manera individual y producir un retraso de marcado posterior.
  • Impide la necesidad de devolución de llamadas rechazadas al PBX de origen mediante el uso de varios intervalos de DS0 para una única llamada.
  • Funciona bien para el redireccionamiento de llamadas rechazadas con los PBX que no tienen la capacidad o no están configurados adecuadamente.
  • Resuelve el problema de devolución de llamadas del PBX devolviendo la llamada a un tercer DS0 en la misma línea T1/E1 a la puerta de enlace que ya ha rechazado la llamada y la ha devuelto (se trata de una condición denominada tromboning o desvío del tráfico a través de un operador exterior). Los tipos troncales CCS gestionan este problema de devolución de llamadas debido a que la información del código de la causa puede devolverse al PBX que activa la lógica de reenrutamiento. Sin embargo, en los troncales de CAS, el PBX no sabe lo que ha ido mal y, a menos que los dígitos se manipulen en la puerta de enlace, el PBX no podrá tomar una decisión fácilmente para reenrutar la llamada sobre un grupo de troncales diferente.

LVBO ofrece la puerta de enlace saliente con la capacidad para supervisar el estado de varias interfaces de red, tanto LAN como WAN, y devolver una señal de ocupado del troncal al PBX si se produjera algún error en cualquiera de los enlaces supervisados. Se pueden supervisar hasta un máximo de 32 interfaces. Si una o todas las interfaces cambian el estado, la puerta de enlace puede configurarse para que envíe una señal de ocupado del troncal al PBX. La razón por la que esta característica se denomina "estado ocupado de voz local" es porque los enlaces locales pueden supervisarse. Esta característica no tiene visibilidad en la red más allá del enlace de la puerta de enlace local.

LVBO sólo funciona en el software actual en CAS y en los troncales analógicos de PBX/PSTN. En los troncales de CCS, la funcionalidad de código de causa puede usarse para informar al switch PBX con el objeto de que realice el redireccionamiento de una llamada rechazada. LVBO puede configurarse de uno de los siguientes modos:

  • Para forzar a los puertos individuales de voz a que pasen al estado ocupado.
  • Para forzar a un troncal T1/E1 completo a que pase al estado ocupado.

En la figura 7 se muestra el funcionamiento de la característica LVBO, incluida una configuración de muestra. En el ejemplo, la puerta de enlace saliente está supervisando dos interfaces: Ethernet e0/1 y WAN s0/1 en nombre del puerto de voz 2/0:1, un troncal de T1 CAS hacia un PBX. Tal y como se muestra en la figura, esta característica sólo es aplicable si el dispositivo de origen es una interfaz de PBX/PSTN, a pesar de que el dispositivo de destino puede ser de cualquier tipo, incluso un dispositivo de voz IP.


Figura 7   Funcionalidad de estado ocupado de voz local


Se aplican las siguientes limitaciones a la característica LVBO:

  • Sólo tiene visibilidad local en el software actual (versión 12.2 de Cisco IOS). Sólo supervisa las interfaces LAN Ethernet (no Fast Ethernet).
  • Sólo se aplica a tipos de troncal analógico y de CAS.

En la tabla 10 se evalúa el mecanismo de estado ocupado de voz local frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 10   Resumen del mecanismo de condicionamiento troncal

Criterios de evaluación  Valor 

Compatible con VoX

Todos

Conexión troncal/Telefonía IP

Conexión troncal (llamadas que se originan en el PBX y terminan en los destinos de telefonía IP)

Plataforma/Versión

Routers de las series Cisco 2600 y 3600 y concentradores de acceso múltiple MC3810; versión 12.1(2)T de Cisco IOS

Tipos de troncal PBX compatibles

Analógico y CAS

Extremo a extremo/Local/nube IP

Local

Por llamada/interfaz/punto final (endpoint)

Por WAN, LAN e interfaz de telefonía

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Ninguna

Mecanismos de CAC basados en medidas

Esta sección del documento se centra en las siguientes técnicas de CAC basadas en medidas:

Se trata del primero de los dos tipos de mecanismos de CAC que añaden visibilidad a la red además de ofrecer información local sobre la puerta de enlace saliente tal y como se ha descrito en las secciones anteriores.

Antes de pasar a describir las características de esta categoría, es necesario proporcionar información básica sobre las sondas SAA (Service Assurance Agent, Agente de garantía del servicio) ya que se trata de la técnica subyacente empleada por los métodos de CAC basados en medidas. Las sondas SAA atraviesan la red hasta un destino IP determinado y miden las pérdidas y retrasos de la red en la ruta atravesada. Estos valores se devuelven a la puerta de enlace saliente para usarlos en la toma de decisiones según las condiciones de la red y su capacidad para transportar una llamada de voz.

Tenga en cuenta los siguientes atributos de los mecanismos de CAC basados en medidas que se derivan del uso de sondas SAA:

  • Debido a que una sonda SAA es un paquete de IP que se dirige a un destino IP, todas las técnicas de CAC basadas en medidas se aplicarán sólo a VoIP (incluso VoIP sobre Frame Relay y VoIP sobre redes ATM).
  • Puesto que las sondas se envían a la red, se produce una cantidad concreta de tráfico de tara al recopilar la información necesaria para el CAC.
  • Si la decisión del CAC para realizar una llamada debe esperar a que una sonda se envíe y vuelva, se producirá un cierto retraso posterior al marcado para la llamada. Este retraso debería ser insignificante en una red diseñada convenientemente.

Agente de garantía del servicio de Cisco

SAA es una característica de gestión de red integrada en el software Cisco IOS que ofrece un mecanismo de análisis de la sobrecarga de la red. También incluye muchas otras características de Cisco IOS. No se ha implementado con el objetivo de conseguir el CAC ni es una parte del conjunto de herramientas que forman el CAC. Sin embargo, sus funciones para medir el retraso de la red y la pérdida de paquetes son útiles como bloques de construcción sobre los que basar las características de CAC. La característica SAA es una extensión de la característica Informe de tiempo de respuesta (RTR, Response Time Reporter) que se encuentra en versiones anteriores del software Cisco IOS.

Las sondas SAA no ofrecen ninguna información de ancho de banda, esté configurado o disponible. Sin embargo, si el ancho de banda de un enlace que se encuentre en cualquier parte de la ruta que seguirá la llamada de voz tiene exceso de suscripciones, es razonable asumir que el retraso en la entrega de paquetes y los valores de pérdidas que la sonda devuelve reflejarán esta circunstancia aunque sea de manera indirecta.

Sondas SAA frente a pings

Las sondas SAA son similares, al menos en el concepto, al conocido mecanismo de conectividad IP mediante ping pero son mucho más sofisticadas. Los paquetes de SAA pueden crearse y personalizarse para imitar el tipo de tráfico para el que están midiendo la red (en este caso un paquete de voz). Un paquete de ping es casi por definición un paquete basado en el mejor esfuerzo y, aunque la precedencia IP esté definida, no parece un paquete de voz ni en tamaño ni en protocolo. Ni tampoco los mecanismos de calidad de servicio implementados en la red clasificarán ni tratarán un paquete de ping como paquete de voz. El retraso y la pérdida experimentada por un ping es, por lo tanto, una medida muy tosca en el peor de los casos del tratamiento al que puede estar sujeto un paquete de voz mientras atraviesa la misma red. Gracias a la introducción de mecanismos de calidad de servicio sofisticados en las estructuras básicas de la red, un ping pasa a ser inutilizable como indicación práctica de la capacidad de la red para llevar voz.

Protocolo SAA

El protocolo SAA es un protocolo cliente/servidor definido en UDP. El cliente crea y envía la sonda y el dispositivo de destino (con el contestador RTR activado) devuelve la sonda al remitente. Las sondas SAA utilizadas para el CAC salen de forma aleatoria por los puertos seleccionados desde el extremo superior del intervalo de puertos de audio definidos por UDP (16384 a 32767). Utilizan un tamaño de paquete basado en el códec que utilizará la llamada. Se puede definir la precedencia de IP si así lo desea. Se usará un encabezado completo de RTP/UDP/IP como el que llevaría un paquete de voz real. En forma predeterminada, la sonda SAA utiliza el puerto RTCP (el número de puerto RTP impar), pero también se puede configurar para usar el puerto de medios RTP (el número de puerto RTP par) si así lo desea.

El SAA se presentó en las plataformas seleccionadas en la versión 12.0(7)T de Cisco IOS. Las plataformas de routers Cisco de mayor capacidad normalmente son compatibles (es el caso, por ejemplo, de las series 7200 y 7500 de Cisco) mientras que las de menor capacidad no lo son (por ejemplo, el router 1750 de Cisco). En el momento en que se redactó este documento, ni los routers de Cisco con acceso por cable ni los teléfonos IP son compatibles con las sondas SAA ni responden a ellas.

Factor de defecto de planificación calculado

La ITU ha estandarizado los problemas de transmisión de la red en ITU G.113. Esta norma define el término "factor de defecto de planificación calculado" (ICPIF, Calculated Planning Impairment Factor) como un cálculo basado en el retraso de la red y en cifras de pérdidas de paquetes. ICPIF produce un único valor que puede usarse como un medidor de los problemas de la red.

ITU G.113 proporciona las siguientes interpretaciones para los valores ICPIF concretos:

  • 5: muy bien
  • 10: bien
  • 20: adecuado
  • 30: caso restrictivo
  • 45: caso restrictivo excepcional
  • 55: es posible que los clientes reaccionen de forma airada

El retraso y la pérdida de información de la sonda SAA se utiliza en el cálculo de un valor ICPIF que se empleará posteriormente como un umbral para las decisiones del CAC basadas en la interpretación de ITU descrita o en los requisitos de una red cliente individual.

Estado ocupado de voz avanzado

AVBO es una mejora de LVBO. Aunque LVBO permite el estado ocupado según las condiciones locales de la puerta de enlace saliente, AVBO añade la función para activar una sonda SAA para uno o varios destinos IP configurados. La información devuelta por la sonda (ya sea la pérdida explícita, los valores de retraso o el umbral de sobrecarga ICPIF) puede utilizarse con el objeto de activar el estado ocupado de la conexión para el PBX.

Por lo tanto, AVBO presenta la posibilidad de poner en estado ocupado a un troncal PBX o a puertos de voz individuales, según las condiciones actuales de la red IP. Esta capacidad se muestra en la figura 8.


Figura 8   Estado ocupado de voz avanzado


El siguiente ejemplo de configuración presenta una configuración de muestra de AVBO en un troncal T1 CAS a un PBX.

controller T1 2/0
 ds0-group 1 timeslots 1-4 type e&m-immediate-start
!
voice-port 2/0:1
  voice-class busyout 4
!
voice class busyout 4 
 busyout monitor Serial0/1
 busyout monitor Ethernet0/1
 busyout monitor probe 1.6.6.48 codec g729r8 icpif 10

Cuando se utiliza el estado ocupado de voz avanzado, se deben recordar las siguientes restricciones y limitaciones:

  • Los resultados de ocupado basados en sondas (basadas en medidas) no son absolutos. Por lo tanto, hay condiciones en las que se producen falsos positivos.
  • Las direcciones IP supervisadas por las sondas se configuran de manera estática (tal y como se muestra en el ejemplo de configuración). Es necesario garantizar, manualmente, que estas direcciones IP sean de hecho los destinos a los que van dirigidas las llamadas. No existe una coordinación automática entre la configuración de sonda y los destinos IP reales hacia los que los pares de marcado de VoIP o un control de acceso pueden dirigir las llamadas.
  • El nodo de destino (el dispositivo que posee la dirección IP a la que se envía la sonda) debe ser compatible con un contestador de SAA.
  • Esta característica no puede enviar una señal de ocupado al troncal PBX local según el estado del troncal de telefonía en el nodo remoto ya que sólo supervisa la red IP.
  • Las características basadas en sondas SAA no funcionan bien en redes en las que la carga de tráfico fluctúa mucho en un periodo de tiempo corto.
  • Tal y como ocurre con LVBO, es posible aplicar esta características sólo a troncales analógicos y de CAS. Los troncales de CCS todavía no son compatibles.

En la tabla 11 se evalúa el mecanismo de AVBO frente a los criterios de evaluación del CAC descritos anteriormente en este documento.

Tabla 11   Resumen del mecanismo de AVBO

Criterios de evaluación  Valor 

Compatible con VoX

Únicamente VoIP

Conexión troncal/Telefonía IP

Conexión troncal (llamadas que se originan en el PBX y terminan en los destinos de telefonía IP)

Plataforma/Versión

2600, 3600, MC3810; versión 12.1(3)T

Tipos de troncal PBX compatibles

Analógico y CAS

Extremo a extremo/Local/nube IP

Nube IP

Por llamada/interfaz/punto final (endpoint)

Por destino IP

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Sondas SAA periódicas

Repliegue de PSTN

El nombre "repliegue de PSTN" es hasta cierto punto un nombre inadecuado ya que es posible redirigir una llamada a cualquiera de las opciones de reenrutamiento tratadas anteriormente en este documento, no sólo la PSTN. E incluso si la llamada se redirige a la PSTN, la redirección puede realizarse mediante la puerta de enlace saliente o mediante el PBX asociado a ella dependiendo de la configuración. Por esta razón, en ocasiones se hace referencia a esta característica como "repliegue de VoIP".

A diferencia de AVBO, el repliegue de PSTN es un mecanismo de CAC por llamada; es decir, el repliegue de PSTN no pone en estado ocupado a ningún troncal ni ofrece indicaciones generales al PBX asociado si la nube IP no puede atender llamadas. La decisión del CAC sólo se activa cuando se intenta configurar la llamada.

Debido a que el repliegue de PSTN está basado en sondas SAA, cuenta con todas las ventajas y desventajas de una técnica basada en medidas. Es inusualmente flexible en el hecho de poder tomar decisiones de CAC basadas en cualquier tipo de red IP, incluso Internet. Todas las redes IP llevarán el paquete de sonda SAA como otro paquete de IP. Por lo tanto, no importa si la red de estructura básica del cliente comprende una o varias redes de proveedores de servicio (SP, Service Provider), Internet o una combinación de estos tipos de redes. El único requisito es que el dispositivo de destino (el propietario de la dirección IP a la que se envía la sonda) sea compatible con la funcionalidad de contestador de SAA.

Este dispositivo de destino debe formar parte de la red cliente en el sitio de destino con una estructura básica de SP en medio. Por lo tanto, el repliegue de PSTN no puede utilizarse directamente con teléfonos IP ni con destinos de aplicación VoIP basados en PC, sino que puede emplearse indirectamente si estos destinos se encuentran detrás de un router de Cisco IOS que sea compatible con el contestador de SAA. No es necesario que el dispositivo de destino sea compatible con la característica de repliegue de PSTN (sólo es una característica de la puerta de enlace saliente). Únicamente es necesario el contestador de sonda SAA.

Sondas SAA usadas para repliegue de PSTN

Tal y como se muestra en la figura 9, cuando se intenta una llamada en la puerta de enlace saliente, se usarán los valores de sobrecarga de la red para el destino IP a fin de permitir o rechazar la llamada. Se ofrecen valores de sobrecarga de la red para el retraso, pérdida o ICPIF al enviar una sonda SAA al destino IP que la llamada está intentando alcanzar. Los valores de umbral para rechazar una llamada están configurados en la puerta de enlace saliente.


Figura 9   Repliegue de PSTN


Almacenamiento en memoria caché de destinos IP

A diferencia de AVBO, el repliegue de PSTN no exige la configuración estática de los destinos IP. El software mantiene una memoria caché de tamaño configurable que realiza un seguimiento de los destinos IP usados más recientemente que han intentado alcanzar las llamadas. Si el destino IP de un nuevo intento de llamada se encuentra en la memoria caché, puede tomarse inmediatamente la decisión del CAC correspondiente a la llamada (los ejemplos 1 y 2 en la figura 10 muestran las situaciones de llamada permitida y rechazada, respectivamente). Si la entrada no aparece en la memoria caché, se iniciará un nueva sonda y se suspenderá la configuración de la llamada hasta que llegue la respuesta de la sonda (ejemplo 3 de la figura 10). Por lo tanto, sólo se aplicará un retraso posterior al marcado adicional para la primera llamada a un nuevo destino IP.


Figura 10   Configuración de llamada de repliegue de PSTN


Una vez que se ha ingresado un destino IP en la memoria caché, se enviará una sonda periódica con un tiempo de espera configurable a ese destino con el objeto de actualizar la información en la caché. Si no se realizan más llamadas a este destino IP, la entrada se desactualizará de la memoria caché y el tráfico de la sonda a ese destino será discontinuo. Por lo tanto, el repliegue de PSTN ajustará de manera dinámica el tráfico de la sonda a los destinos IP que están viendo la actividad de la llamada.

Formato de sondas SAA

Cada sonda consiste en varios paquetes (se trata de un parámetro configurable de la característica). El retraso, la pérdida y los valores de ICPIF ingresados en la memoria caché para el destino IP serán la media de todas las respuestas.

Si la llamada utiliza los códecs G.729 y G.711, los tamaños de los paquetes de la sonda imitarán a los de un paquete de voz para ese códec. Otros códecs usarán sondas de tipo G.711. En las versiones del software Cisco IOS posteriores a la versión 12.1(3)T, es posible que otros códecs que elija con sus propias sondas exactas sean compatibles.

La precedencia IP de los paquetes de sonda también pueden configurarse para imitar con más exactitud la prioridad de un paquete de voz. Este parámetro debería ser igual que la precedencia IP utilizada para otros paquetes de medios de voz en la red.

Configuración de repliegue de PSTN

La configuración de repliegue de PSTN sólo se aplica a llamadas iniciadas por la puerta de enlace saliente, por lo que no tiene relación con las llamadas recibidas por la puerta de enlace. El nodo de destino (con frecuencia la puerta de enlace de terminación, aunque no tiene que ser necesariamente así) debería configurarse con la característica del contestador de SAA. En la mayoría de las redes, las puertas de enlace generan llamadas de una a otra de manera que cada puerta de enlace es a la vez puerta de enlace saliente y de terminación. Sin embargo, en algunas redes (por ejemplo, redes de SP), en ocasiones la dirección del tráfico de llamadas es sólo en una dirección: o saliente o entrante.

La configuración de repliegue de PSTN se realiza globalmente y, por lo tanto, se aplica a todas las llamadas que intente la puerta de enlace. No puede aplicar de forma selectiva el repliegue de PSTN sólo a las llamadas iniciadas por algunas interfaces de PSTN/PBX.

Para activar el repliegue de PSTN, ingrese los siguientes comandos de configuración globales:

  • Puerta de enlace saliente: comando call fallback
  • Nodo de destino: comando rtr responder

El comando call fallback tiene las siguientes palabras clave con los siguientes valores predeterminados:

Palabra clave del comando call fallback  Objetivo de la palabra clave  Valor predeterminado 

cache-size

Configurar el tamaño de la memoria caché

128

cache-timeout

Configurar el tiempo de espera de la memoria caché

600s

instantaneous-value-weight

Configurar el peso del valor instantáneo

66

jitter-probe

Configurar los parámetros de fluctuación de la sonda

 

  • num-packets

Configurar la cantidad de paquetes de la sonda

15

  • precedence

Configurar la precedencia de los paquetes de la sonda

2

  • priority-queue

Hacer que las sondas se envíen a través de la cola prioritaria (PQ, Priority Queuing) de voz

desactivado

key-chain

Configurar la cadena de claves MD5

ninguno

map

Configurar la asignación de IP

ninguno

probe-timeout

Configurar el tiempo de espera de la sonda

30s

threshold

Configurar el umbral de ICPIF o de retraso/pérdida

 

  • delay n loss m

Configurar el umbral de retraso

ninguno

  • icpif n

Configurar el umbral de ICPIF

10

Escalabilidad de repliegue de PSTN

Con frecuencia los clientes con redes de gran tamaño muestran su preocupación sobre el repliegue de PSTN ya que causa una gran cantidad de tráfico de sonda en las redes. En redes de tamaño más pequeño, las puertas de enlace de terminación pueden usarse como los nodos de destino de las sondas. En otras palabras, las direcciones IP mantenidas en la caché de la puerta de enlace saliente serán aquellas de las puertas de enlace de terminación a las que se envía el tráfico de llamadas.

Sin embargo, en el caso de sitios de gran tamaño o de oficinas centrales que pueden tener varias puertas de enlace de terminación o en el caso de sitios con aplicaciones de telefonía IP o basadas en PC como destinos, o bien en el caso de sitios que cuenten con un router de borde de WAN independiente de la puerta de enlace de terminación, las direcciones IP de destino del tráfico de llamadas pueden asignarse a un conjunto más pequeño de destinos de sonda que se mantendrán en la memoria caché de la siguiente manera.

  • Considere un ejemplo basado en la figura 11. Hay una gran cantidad de teléfonos IP en el sitio 6 y cada uno de ellos cuenta con una dirección IP única. Si el sitio 1 llama a un teléfono IP situado en el sitio 6, la caché del sitio 1 no tiene que contener una entrada para cada destino IP en el sitio 6 ni enviar una sonda independiente a cada dirección IP. Es posible asignar todos los destinos de llamada IP del sitio 6 a la dirección IP del router de borde de WAN del sitio 6 de manera que una única sonda del sitio 1 al 6 pueda sondar la información del CAC para todas las llamadas destinadas al sitio 6. Se aplica el mismo principio si hay varias puertas de enlace de terminación en el sitio 6. Todas las direcciones IP pueden asignarse al router de borde de WAN, que podrá ser propiamente o no una puerta de enlace de terminación.

Figura 11   Escalabilidad de repliegue de PSTN


Por lo tanto, el tráfico de sonda puede reducirse sustancialmente al enviar sondas a los destinos IP que representan la parte de la red que tiene más probabilidad de sobrecargarse (la estructura básica y el borde WAN) y al no enviar el tráfico de sonda a través de oficinas centrales de alta velocidad o de la estructura básica de LAN, cuya probabilidad de sobrecargarse es mucho menor. El mismo mecanismo de escalabilidad también ofrece un mecanismo compatible con los destinos IP que no son compatibles con la funcionalidad del contestador de SAA.

Resumen de repliegue de PSTN

El repliegue de PSTN es un mecanismo de CAC independiente de la topología y de amplia implementación que puede usarse en cualquier estructura básica sin tener en cuenta si el cliente posee el equipo de estructura básica o la tecnología utilizada en ella, o si posee el equipo del proveedor utilizado en la estructura básica.

Se deberían considerar los siguientes atributos del repliegue de PSTN al diseñar una red:

  • Puesto que está basado en sondas IP, el repliegue de PSTN sólo se aplica a redes de VoIP.
  • El repliegue de PSTN no vuelve a enrutar llamadas en progreso cuando las condiciones de la red cambian.
  • Sólo se aplicará un ligero aumento en el retraso posterior al marcado en la primera llamada a un destino que no se encuentre aún en la memoria caché.
  • No hay interacción entre el temporizador de sonda SAA y el ajuste del temporizador de H.225. La sonda SAA se produce antes de que se envíe la configuración de llamada de H.323 al destino. El temporizador de H.225 se produce después de que se haya enviado la configuración de llamada de H.323.
  • El repliegue de PSTN está basado en las medidas y, por lo tanto, no es absoluto. Funcionará bien en condiciones de tráfico estable con subidas y bajadas graduales, pero no ocurrirá así con tráfico que fluctúe rápidamente y con subidas y bajadas intermitentes.
  • Se podría producir una decisión del CAC errónea basada en información no actual debido a la naturaleza periódica de las sondas.
  • Los destinos de proxy para las sondas pueden usarse efectuando las asignaciones de direcciones IP de destino a una cantidad más pequeña de direcciones IP de los nodos situados entre la puerta de enlace saliente y las puertas de enlace de terminación.
  • Las sondas no toman medidas del ancho de banda, sólo de retrasos y pérdidas.
  • Es posible configurar la autenticación de la cadena de claves MD5 por motivos de seguridad para garantizar que las sondas sean iniciadas únicamente por orígenes confiables, que a su vez sortearán ataques de "denegación de servicio" producidos por orígenes no confiables que inician grandes cantidades de sondas.

En la tabla 12 se evalúa el mecanismo de repliegue de PSTN frente a los criterios de evaluación del CAC descritos anteriormente en este documento.

Tabla 12   Resumen del mecanismo de repliegue de PSTN

Criterios de evaluación  Valor 

Compatible con VoX

Únicamente VoIP

Conexión troncal/Telefonía IP

Conexión troncal (llamadas que se originan en el PBX y terminan en los destinos de telefonía IP)

Plataforma/Versión

Cisco 2600/3600, MC3810: versión 12.1.(3)T

AS5300: versión 12.2.(2)T

7200/7500 compatible con el contestador de SAA

Tipos de troncal PBX compatibles

  • Todos los tipos de señalización troncal de PBX/PSTN (analógica, digital CAS y CCS)
  • Para CAS analógica y digital (destino IP alternativo, devolución de llamadas)
  • Para CCS digital (rechazar la llamada al PBX o a la PSTN para reenrutamiento)

Extremo a extremo/Local/nube IP

Nube IP

Por llamada/interfaz/punto final (endpoint)

Por destino IP activo o almacenado en caché

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Sólo para la primera llamada que inicia la sonda

Tara de mensajería de red

Sondas SAA periódicas

Mecanismos de CAC basados en recursos

En esta sección se tratan las siguientes tres técnicas de CAC basadas en recursos:

Al igual que ocurre con las técnicas de CAC basadas en medidas, estas técnicas añaden visibilidad en la red además de información local en la puerta de enlace saliente que puede usarse para el CAC tal y como se ha descrito en secciones anteriores.

Cálculo de recursos frente a reserva de recursos

Existen dos tipos de mecanismos de CAC basados en recursos:

  • Los que supervisan el uso de algunos recursos y calculan un valor que afectará a la decisión del CAC.
  • Los que reservan los recursos para la llamada.

Los mecanismos de reserva son los únicos que pueden garantizar la calidad del servicio (QoS) durante la llamada. El resto de mecanismos de CAC (locales, basados en medidas y basados en el cálculo de recursos) simplemente toman una decisión una vez antes de la configuración de la llamada según lo que se sepa de las condiciones de la red en ese momento.

Los siguientes recursos son de interés para las llamadas de voz:

  • Los intervalos de tiempo DS0 en los troncales TDM de origen y de terminación.
  • Los recursos DSP en las puertas de enlace de origen y terminación.
  • Uso de la CPU de los nodos (normalmente las puertas de enlace).
  • Uso de memoria de los nodos (normalmente las puertas de enlace).
  • Disponibilidad de ancho de banda en uno o varios enlaces de la ruta que tomará la llamada.

En el software Cisco IOS actual (versión 12.2), los métodos del CAC de cálculo de recursos en las secciones siguientes consideran la disponibilidad de DS0 y DSP de la puerta de enlace de terminación (RAI) junto con el ancho de banda en un nivel alto (gestión de ancho de banda de la zona de control de acceso). El único mecanismo actual de reserva de recursos (RSVP) sólo considera la disponibilidad del ancho de banda.

Indicación de disponibilidad de recursos

RAI es una característica de H.323v2 que describe un mensaje de RAS que se envía desde la puerta de enlace de terminación al control de acceso con el objeto de entregar información sobre la capacidad actual de la puerta de enlace para recibir más llamadas. El control de acceso no sabe los recursos individuales o el tipo de recursos que tiene en cuenta la puerta de enlace. Es ni más ni menos que una indicación que puede alternar entre el "sí" o el "no" enviada por la puerta de enlace de terminación para controlar si las llamadas de voz siguientes se enrutan a la puerta de enlace.

Como mecanismo de CAC, RAI es único en su capacidad para ofrecer información en la conexión de POTS de terminación. En este documento hemos hablado de otros mecanismos que permiten que se tomen decisiones de CAC según la información local en la puerta de enlace saliente y según la nube IP entre la puerta de enlace saliente y las de terminación. Ningún otro mecanismo de CAC puede mirar la disponibilidad de recursos para terminar la llamada de POTS en la puerta de enlace de terminación (este es el valor que RAI trae a la tabla).

Puesto que se trata de una indicación entre la puerta de enlace y el control de acceso, sólo se aplica RAI a las redes de voz de H.323 que utilizan un diseño de control de acceso. RAI también es único en el hecho de que la decisión de CAC está controlada por la puerta de enlace de terminación. En los otros métodos, la decisión de CAC está controlada por la puerta de enlace saliente o por el control de acceso.

Cálculo de puerta de enlace de recursos

El cálculo para tomar la decisión de "sí" o "no" se realiza en la puerta de enlace. Distintas plataformas de puerta de enlace pueden usar algoritmos diferentes. La norma H.323 no prescribe el cálculo ni los recursos que se van a incluir en el cálculo. Solamente especifica el formato de mensaje de RAI y el hecho de que el control de acceso debe detener el enrutamiento de llamadas a una puerta de enlace que ha indicado su imposibilidad de recibir más llamadas hasta el momento en que la puerta de enlace informe al control de acceso que puede recibirlas de nuevo.

Para medir la disponibilidad de recursos para una llamada de los routers de las series 2600 y 3600 de Cisco, el algoritmo de cálculo considera cada llamada como una unidad según la siguiente fórmula:

  • Cada DS0 libre es una unidad.
  • Cada DSP de complejidad alta son dos unidades.
  • Cada DSP de complejidad media son cuatro unidades.

RAI se calcula por plataforma, no por interfaz T1/E1 ni por tarjeta (por módulo de red o específicamente por NMM-HDV en el caso de los routers de las series 2600 y 3600 de Cisco). Sólo los DS0 que se alcancen mediante un par de marcado de VoIP se incluirán en el cálculo.

Dónde y cómo se usa RAI en las redes de proveedores de servicios

RAI es una característica indispensable en las redes de SP que ofrecen servicios de llamada de VoIP como llamadas con tarjeta de crédito o débito y servicios de telefonía de larga distancia de VoIP. La estructura general de estas redes se muestra en la figura 12.


Figura 12   Topología de red VoIP de proveedor de servicio


Alrededor del mundo hay POP en los que los bastidores de puertas de enlace (normalmente servidores de acceso Cisco AS5300) se conectan a la PSTN con los troncales T1/E1 (con frecuencia troncales de PRI). El enrutamiento de llamadas se gestiona a través de varios niveles de controles de acceso tal y como se muestra en la figura 12. El volumen de llamadas es alto y estas puertas de enlace sólo manejan tráfico de voz, pero no tráfico de datos más allá del IP Routing mínimo y el tráfico de gestión de red.

Cuando un cliente de la Costa Oeste marca en la red y marca un número de la Costa Este, el control de acceso de la Costa Este debe seleccionar una puerta de enlace de la Costa Este que cuente con un troncal de PSTN disponible para terminar la llamada, de lo contrario, se producirá un error en la llamada del cliente. Si esto ocurre, o la puerta de enlace saliente debe reintentar la llamada o el cliente deberá volver a llamar. En cualquier caso, no hay garantía de que la misma puerta de enlace de terminación que ya no tiene capacidad no se vuelva a elegir de nuevo.

Ambas situaciones son ineficaces y ofrecen un servicio al cliente deficiente. Por lo tanto, es importante que el control de acceso no enrute las llamadas a un control de acceso de terminación que no pueda finalizar la llamada, en este caso no sería debido a la capacidad IP sino a la capacidad troncal de la PSTN.

En general, el control de acceso equilibrará la carga de las llamadas mediante las puertas de enlace de terminación de esta zona. Sin embargo, las puertas de enlace podrían tener distintos niveles de capacidad T1/E1 y con un equilibrio de carga alta, es posible que una puerta de enlace pudiera quedarse con menos recursos que la otra. Es en esta situación en la que RAI se vuelve imprescindible, de manera que la puerta de enlace de terminación sobrecargada puede iniciar una indicación al control de acceso informando que está demasiado ocupada para recibir más llamadas.

Dónde y cómo se usa RAI en redes de empresas

Por lo general, RAI es menos aplicable en redes de empresas que en redes de SP debido a que con frecuencia sólo hay una puerta de enlace en cada sitio, tal y como se muestra en la figura 13. Esto casi siempre es verdad para la gran cantidad de sitios pequeños que se conectan a una cantidad mucho menor de sitios grandes en la red de empresas típica. Incluso en sitios grandes, puede haber varios troncales T1/E1 al PBX asociado, aunque pocas veces haya varias puertas de enlace.


Figura 13   Topología de red VoIP empresarial


Si sólo una puerta de enlace puede terminar una llamada a un usuario llamado (donde un usuario llamado es un PBX y una puerta de enlace concretos en la red), el RAI no ofrecerá inteligencia de red que aún no esté disponible. Sin puertas de enlace alternativas para manejar llamadas adicionales, siempre habrá una llamada que no se producirá cuando la única puerta de enlace de terminación esté demasiado ocupada. Además, en redes de empresas, la probabilidad de sobrecarga normalmente será más alta en la nube IP que en la cantidad de troncales de POTS de terminación. En las redes de SP que se han tratado anteriormente, la sobrecarga es más común en los troncales de POTS de terminación que en la nube IP.

A pesar de estas limitaciones, se puede seguir usando RAI en las redes para empresas siempre que las conexiones de puerta de enlace-PBX en los sitios remotos sean troncales T1/E1. Si la puerta de enlace de terminación está demasiado ocupada, se activará un reenrutamiento de PSTN en lugar de seleccionar una puerta de enlace alternativa como en la situación de red del proveedor de servicio (SP).

Funcionamiento de RAI

El debate sobre dónde y cómo se usa RAI en redes de proveedor de servicio y de empresa muestra claramente que RAI es más útil en situaciones donde varias puertas de enlace de terminación pueden llegar al mismo número de teléfono (llamado) de destino. No obstante, RAI es valioso en cualquier situación en la que se desee impedir que una llamada se enrute a una puerta de enlace que no tenga la capacidad de POTS para terminar la llamada.

Cuando un control de acceso recibe una indicación de que RAI no está disponible procedente de una puerta de enlace, elimina esa puerta de enlace del algoritmo de selección de puertas de enlace para los números de teléfono que la puerta de enlace terminaría normalmente. Una indicación de que RAI está disponible recibida posteriormente devolverá la puerta de enlace al algoritmo de selección del control de acceso.

RAI es una característica opcional de H.323. Cuando se implementa una red, por lo tanto, es conveniente comprobar que tanto las puertas de enlace como los controles de acceso en cuestión sean compatibles con esta característica. Los controles de acceso de Cisco son compatibles con RAI. La compatibilidad de la puerta de enlace de Cisco con RAI se explica en una sección posterior de este documento.

Configuración de RAI

La configuración de RAI en la puerta de enlace se realiza con umbrales de marca de agua alta y agua baja, tal y como se muestra en la figura 14. Cuando el uso de los recursos según el algoritmo de cálculo proporcionado anteriormente va por encima de la marca de agua alta (configurada como un porcentaje), se enviará una indicación de que RAI no está disponible al control de acceso. Cuando la disponibilidad del recurso cae por debajo de la marca de agua baja, se envía una indicación de que RAI está disponible al control de acceso. Para impedir la aparición de histéresis basada en la llegada o desconexión de una llamada, las marcas de agua alta y de agua baja deberían configurarse en algunos puntos de porcentaje aparte.


Figura 14   Configuración de RAI


Para configurar RAI, utilice el comando de configuración de puerta de enlace resource threshold [all] [high valor en %] [low valor en %].

Compatibilidad con la plataforma RAI

El servidor de acceso Cisco AS5300 es compatible con RAI desde la versión 12.0(5)T de Cisco IOS. Los routers de las series 2600 y 3600 de Cisco son compatibles con RAI sólo para conexiones T1/E1, aunque no para troncales analógicos desde la versión 12.1.3T. Las otras puertas de enlace de Cisco IOS todavía no son compatibles con RAI, como es el caso de la versión 12.1(5)T o 12.2). El cálculo de RAI incluye DSP y DS0 y es posible que no sea el mismo para todas las plataformas. En el software actual, la CPU y la memoria no se incluyen aún en la indicación de disponibilidad de RAI.

En la tabla 13 se evalúa el mecanismo de RAI frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 13   Resumen del mecanismo de RAI

Criterios de evaluación  Valor 

Compatible con VoX

Únicamente VoIP

Conexión troncal/Telefonía IP

  • Conexión troncal
  • Potencialmente telefonía IP pero CM aún no es compatible con RAI

Plataforma/Versión

  • Servidor de acceso Cisco AS5300: versión 12.0(5)T de Cisco IOS
  • Routers de las series 2600 y 3600 de Cisco T1/E1: versión 12.1(3)T de Cisco IOS

Tipos de troncal PBX compatibles

Todos

Extremo a extremo/Local/nube IP

Local en la puerta de enlace de terminación (recursos DSP y DS0; dependiente de la plataforma del algoritmo)

Por llamada/interfaz/punto final (endpoint)

Por puerta de enlace

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

RAI ocasional se alterna entre la puerta de enlace y el control de acceso

Ancho de banda de zona de control de acceso

Otro mecanismo de CAC que es específico de las redes de control de acceso H.323 es la capacidad del control de acceso para imponer limitaciones de ancho de banda en algunas zonas. Los diferentes niveles del software Cisco IOS ofrecen capacidades específicas distintas dentro de esta característica. En las versiones 12.1(5)T y 12.2 de Cisco IOS, el control de acceso es capaz de limitar tanto el ancho de banda de las llamadas en su zona local como el ancho de banda utilizado entre su propia zona y cualquier otra zona remota de la red.

Funcionamiento de ancho de banda de zona de control de acceso

La traducción de direcciones y la gestión de zonas son dos de las funciones principales de un control de acceso H.323. El ancho de banda de zona permite que el control de acceso controle fundamentalmente la cantidad de llamadas simultáneas que pueden estar activas. Con el objetivo de comprender cómo funciona la característica, supongamos que una llamada de voz es igual a 64 kbps de ancho de banda. La forma en que el límite de la cantidad de llamadas del control de acceso se traduce en el ancho de banda real utilizado por esas llamadas se tratará más adelante en otra sección.

Topología de zona única

En la figura 15 se muestra una red de control de acceso de zona única con dos puertas de enlace que muestran el CAC del control de acceso en su forma más sencilla. Si el ancho de banda de la WAN del enlace entre las dos puertas de enlace no puede llevar más de dos llamadas, deberá configurarse el control de acceso de manera que deniegue la tercera llamada. Si asumimos que cada llamada es de 64 kbps, se configurará el control de acceso con una limitación en el ancho de banda de la zona de 128 kbps para lograr el CAC en esta sencilla topología.


Figura 15   Topología simple de zona única


Sin embargo, la mayoría de las redes no son tan simples como la que aparece en la figura 15. En la figura 16 se muestra una topología más compleja pero sigue estando configurada como una red de zona única. En esta topología, los tramos en cada nube de WAN tienen una prestación de ancho de banda independiente y, por lo tanto, capacidades distintas como la cantidad de llamadas de voz que pueden pasar a través del tramo. Los números en las tramos de WAN de la figura 16 muestran la cantidad máxima de llamadas que pueden realizarse a través de ese tramo.


Figura 16   Topología compleja de zona única


Considere ahora que el ancho de banda de la zona del control de acceso todavía está definido en un máximo de 128 kbps, por lo que no se permitirán más de dos llamadas simultáneas. Este es el comportamiento deseado de la red si ambas llamadas se producen en el sitio 1 (el control de acceso protegerá el ancho de banda del enlace WAN del sitio 1 al punto de agrupación de WAN al no permitir más de dos llamadas a través de ese enlace). Pero si ambas llamadas se encuentran en el sitio de las oficinas principales, no hay razón alguna para permitir sólo dos llamadas porque hay mucho ancho de banda en la estructura básica de la oficina central.

Topología de zona múltiple

Para resolver el problema de zona única de reducir la red a las funciones del enlace WAN de menor capacidad en cualquier parte de la red, podrá diseñar la red con varias zonas de control de acceso. Un buen punto de partida será crear una zona por sitio tal y como se muestra en la figura 17.


Figura 17   Topología simple para empresas de varias zonas


El control de acceso del sitio 1 limita la cantidad de llamadas activas en el sitio 1 (sin tener en cuenta dónde se originan o terminan esas llamadas) a dos (128 kbps). Debido a que sólo hay una puerta de enlace en el sitio 1, no hay necesidad de configurar un límite para el tráfico de llamadas dentro de la zona, ya que todo este tráfico estará limitado a dos llamadas para proteger el enlace WAN que conecta con el sitio 1.

En el sitio 2 también hay una puerta de enlace y, por lo tanto, no hay necesidad de limitar el tráfico de llamadas en la zona. Hay límites distintos dentro de la zona para las siguientes situaciones:

  • Las llamadas entre el sitio 2 y el de oficinas principales (aquí el factor restrictivo son las cuatro llamadas máximas permitidas en el enlace WAN que conecta el sitio 2)
  • Las llamadas entre el sitio 2 y el sitio 1 (aquí el factor restrictivo son las dos llamadas máximas permitidas en el enlace WAN que conecta el sitio 1).

El sitio de las oficinas principales tiene una configuración parecida salvo por el hecho de que las llamadas son ilimitadas dentro del sitio, no porque haya una puerta de enlace, sino porque entre las puertas de enlace hay un ancho de banda amplio en ese sitio.

En la topología de red de la figura 17, el CAC del control de acceso ofrece granularidad suficiente para proteger el tráfico de voz a través de enlaces de acceso WAN de velocidad baja. Sin embargo, tenga en cuenta ahora otra topología de red en la que hay varias puertas de enlace por zona y cada puerta de enlace (los sitios remotos) tiene un enlace WAN distinto al punto de agrupación. En la figura 18 se muestra una topología de red de este tipo.


Figura 18   Topología compleja para empresas de varias zonas


De las tres puertas de enlace en el sitio 1 remoto, el enlace de acceso WAN más bajo puede llevar un máximo de dos llamadas simultáneas. Debido a que la limitación de ancho de banda está configurada por zona y no por puerta de enlace, no hay posibilidad dentro del CAC del control de acceso para limitar las llamadas a las puertas de enlace específicas dentro de la zona. Su mejor opción, por lo tanto, es configurar la red para el enlace de denominador común más bajo: para los sitios 1 y 2 remotos, el enlace de denominador común más bajo es un ancho de banda de 128 kbps o dos llamadas.

Esta configuración garantizará una calidad de voz adecuada en todo momento pero también derrocha las puertas de enlace que pueden terminar más llamadas sin suscribir en exceso el ancho de banda de la WAN. En esta configuración de red, el CAC se activará demasiado pronto y desviará ciertas llamadas a la PSTN cuando de hecho podrían haber sido llevadas por la WAN. Por lo que en este tipo de topología, el CAC del control de acceso no es suficiente para proteger la calidad de voz por el enlace WAN y también optimizar el uso de banda ancha de todos los enlaces WAN.

La última configuración que vamos a considerar es una red del proveedor de servicio en la que las puertas de enlace en los POP están conectadas mediante Fast Ethernet al router de borde de WAN, que se muestra en la figura 19.


Figura 19   Topología de proveedor de servicio con varias puertas de enlace por zona


En esta red, el CAC del control de acceso es de nuevo suficiente, aun cuando haya varias puertas de enlace por zona, ya que las conexiones a puertas de enlace específicas dentro de ella no son los enlaces que necesitan protección. El ancho de banda que necesita protección es el enlace de acceso WAN que va a la estructura básica que agrupa el tráfico de llamadas de todas las puertas de enlace. La limitación de ancho de banda del control de acceso para la zona limitará de hecho la cantidad de llamadas sobre ese enlace. Se asume que el enlace de estructura básica OC-12 está manipulado en exceso y no necesita protección.

En resumen, una red de control de acceso de varias zonas ofrece los siguientes atributos de CAC:

  • El ancho de banda de WAN en cada sitio de conexión puede protegerse, siempre que cada sitio sea también una zona. (Para los sitios remotos pequeños en una red de empresa, con frecuencia se traduce en una zona por puerta de enlace, lo que puede no ser un diseño práctico.)
  • El ancho de banda dentro de un sitio puede protegerse si fuera necesario, aunque con frecuencia esto tiene poco valor porque sólo hay una puerta de enlace en el sitio (oficinas pequeñas remotas o un punto de entrada CPE a un servicio de redes administradas del proveedor de servicio) o porque una LAN de alta velocidad se encuentra entre las puertas de enlace (sitios de gran tamaño y POP de proveedores de servicio).
  • El CAC del control de acceso es un método bien adaptado para limitar la cantidad de llamadas entre sitios.
  • El CAC del control de acceso no puede proteger el ancho de banda en los segmentos de WAN que no estén directamente asociados con las zonas. Por ejemplo, el enlace de la estructura básica marcado con 20 llamadas en la topología simple para empresas que se muestra en la figura 17, no puede estar protegido por el CAC del control de acceso a menos que siga el enfoque del denominador común más bajo. De ahí que abastezcamos en exceso el ancho de banda en este enlace para permitir la cantidad máxima de llamadas posible.
Diseño de zona por puerta de enlace

Debido a que el diseño de zona por puerta de enlace ofrece la granularidad más fina del CAC del control de acceso, merece la pena dedicarle un poco más de tiempo. En las redes de empresas, con frecuencia esto tiene sentido desde los siguientes puntos de vista:

  • Consideraciones geográficas.
  • CAC para proteger el enlace de acceso WAN en un sitio que contiene una única puerta de enlace.
  • Los planes de marcado coinciden con frecuencia con sitios, por lo que un prefijo de zona se traduce fácilmente en una puerta de enlace que preste servicio a ese sitio si la puerta de enlace es equivalente a una zona.

Un control de acceso es un concepto lógico, no físico. Cada control de acceso, por lo tanto, no significa una casilla independiente en la red sino que significa simplemente una declaración independiente de "zona local" en la configuración.

Allí donde las imágenes de software combinadas de puerta de enlace y control de acceso estén disponibles (como en la versión 12.1(5)T y 12.2 de Cisco IOS), cada puerta de enlace (sobre todo en sitios remotos de pequeño tamaño) puede ser a la vez su propio control de acceso siempre que la CPU de esa plataforma sea suficiente para todas estas funciones. (Es posible que también sirva de router de borde de WAN.)

Sin embargo, un diseño de zona por puerta de enlace desbarata el aspecto de escalabilidad que los controles de acceso incorporan a las redes H.323 y niega en gran medida el "plan de marcado centralizado" de las redes de los controles de acceso a menos que el plan de marcado se implemente completamente en un nivel independiente usando los controles de acceso del directorio. Por lo tanto, debería considerar cuidadosamente las ventajas y limitaciones de dicho diseño.

Control de acceso en redes del administrador de llamadas

De todos los mecanismos de CAC explicados en este documento, el ancho de banda de la zona de control de acceso es el único método aplicable a redes de varios sitios del administrador de llamadas distribuido. En esta situación, el administrador de llamadas se comporta como una puerta de enlace de VoIP al control de acceso H.323, tal y como se muestra en la figura 20.


Figura 20   Control de acceso en una topología de administrador de llamadas


Cálculo del ancho de banda de zona

El control de acceso no tiene ningún conocimiento de la topología de red ni sabe cuánto ancho de banda está disponible para las llamadas. Tampoco sabe la cantidad de ancho de banda configurada en los enlaces que está utilizando actualmente otro tráfico. El control de acceso toma una cantidad fija de ancho de banda, configurada estáticamente en el control de acceso tal y como se ha mostrado en los ejemplos de red anteriores y, a continuación, resta una pequeña cantidad de ancho de banda para cada llamada configurada. El ancho de banda vuelve a la agrupación cuando se desconecta una llamada. Si una solicitud de una nueva llamada provoca que el ancho de banda restante sea menor que cero, se denegará la llamada. Por lo tanto, el control de acceso no realiza ningún tipo de reserva de ancho de banda sino que simplemente hace un cálculo estático para decidir si se debe permitir una nueva llamada.

Serán las puertas de enlace las responsables de informar al control de acceso sobre la cantidad de ancho de banda necesario para una llamada. Así que las puertas de enlace de video podrían solicitar un ancho de banda diferente para cada configuración de llamada: una sesión de video podría necesitar 256 kbps mientras que otra 384 kbps. Las puertas de enlace de voz deberían tener en cuenta el códec, la encapsulación de capa 2 y las características de compresión (como cRTP) al solicitar ancho de banda desde el control de acceso. Algunas veces, estas características se desconocen en el mismo momento de la configuración de la llamada, en cuyo caso es posible emitir una petición de cambio de ancho de banda al control de acceso después de la configuración de la llamada para ajustar la cantidad de ancho de banda utilizada por ella. En la actualidad, Cisco no ha implementado aún esta funcionalidad.

Los ejemplos anteriores han asumido un ancho de banda fijo de 64 kbps por llamada, que es la forma en que las puertas de enlace H.323 de Cisco están implementadas en el software actual. El códec y las otras características que determinan el ancho de banda, como el cRTP, no se tienen en cuenta en la actualidad cuando el cálculo de ancho de banda de la zona del control de acceso ha considerado el ancho de banda de una llamada. Este aspecto se modificará en versiones futuras del software pero hasta entonces, la implementación de esta característica exigirá un cálculo matemático manual de la cantidad de llamadas que deben permitirse multiplicando n por 64 kbps por llamada y el ancho de banda WAN total disponible.

Sin embargo, el ancho de banda de la zona del control de acceso sigue siendo una ciencia inexacta porque existe la posibilidad de que la puerta de enlace no sepa con exactitud el ancho de banda necesario para la llamada. Las tecnologías de capa 2 utilizadas en la WAN o en tramos de la estructura básica de la red, así como las características de salto por salto, como cRTP, pueden usarse más en la red de lo que la puerta de enlace es consciente. A continuación se explican algunos ejemplos:

  • La puerta de enlace puede estar asociada a un segmento de Ethernet en una red de oficinas centrales donde no se aplica cRTP y donde los encabezados de capa 2 son más grandes de lo que serían para la retransmisión por frame (frame relay) o MLP en los tramos de WAN.
  • Es posible utilizar un códec distinto en la red de oficinas centrales a partir de los segmentos de WAN con lo que se sacaría partido a la funcionalidad de conversión de código del códec en el borde de WAN.
  • En la estructura básica de la red, es posible utilizar ATM como la tecnología de transporte. Además, a la hora de calcular el ancho de banda habrá que tener en cuenta el rellenado de celda.
  • Es posible utilizar cRTP en el router de borde de WAN.

Tanto la puerta de enlace como el control de acceso no son conscientes de la información de topología de red descrita a menos que la puerta de enlace sea también el router de borde de WAN, en cuyo caso la puerta de enlace/router de borde tendrá un poco más de visibilidad. Aún así, es probable que siga sin ver una estructura básica de ATM y, por lo tanto, no dará cuenta de ello.

Configuración del ancho de banda de zona

A partir de las versiones 12.1(5)T y 12.2 de Cisco IOS, es posible configurar los siguientes tipos de limitaciones de ancho de banda de zona en el control de acceso:

  • El ancho de banda máximo para todo el tráfico de H.323 entre la zona local y una zona remota especificada. (Si así lo desea, puede repetir esta configuración de manera individual para cada zona remota).
  • El ancho de banda máximo permitido para una sola sesión en la zona local (por lo general utilizado para aplicaciones de video, no para voz).
  • El ancho de banda máximo para todo el tráfico de H.323 permitido de forma colectiva en todas las zonas remotas.

Para configurar el ancho de banda de zona del control de acceso, utilice los siguientes comandos:

  • bandwidth {interzone | total | session} {default | zone nombre-zona} ancho de banda-máx
  • bandwidth remote ancho de banda-máx

Resumen de ancho de banda de la zona de control de acceso

El CAC del control de acceso funciona bien en diseños de red en los que se desee limitar la cantidad de llamadas entre sitios. Esto puede ser necesario debido a las limitaciones de ancho de banda o de las políticas empresariales. Si las limitaciones de ancho de banda se encuentran en los tramos de WAN, se pueden realizar los cálculos manuales para traducir la cantidad máxima de llamadas que se permitirán entre los sitios a una cifra de ancho que banda que provocará que el control de acceso deniegue las llamadas que superen esa cantidad.

El control de ancho de banda de la zona de control de acceso es una parte fundamental de los diseños de red de video de H.323. En este caso, el ancho de banda es algo más que una simple cuestión ya que el video utiliza mucho más ancho de banda por sesión que la voz. Además, diferentes sesiones de video pueden solicitar distintas cantidades de ancho de banda para las transmisiones de video con lo que el método de cálculo manual utilizado para la voz no resulta muy útil.

Una cosa más que hay que recordar al diseñar el CAC del control de acceso es que los controles de acceso redundantes complican de alguna forma algunos de estos aspectos. Por ejemplo, si se utiliza HSRP en los controles de acceso para la redundancia, no habrá ninguna base de datos compartida entre los controles de acceso. Si el control de acceso principal falla, el secundario puede retomar la acción pero no sabrá cuánto ancho de banda se está utilizando en la actualidad en la zona ni cuántas llamadas están activas actualmente. El control de acceso secundario permitirá demasiadas llamadas en la red hasta que la información converja de nuevo para reflejar la realidad. Si se utilizan controles de acceso alternativos como método de redundancia, se evitará este problema.

La principal ventaja del CAC del control de acceso es que se trata del único método de CAC que puede incorporar redes mixtas de puertas de enlace de Cisco IOS y administradores de llamadas con teléfonos IP.

En la tabla 14 se evalúa el mecanismo de ancho de banda de la zona de control de acceso frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 14   Resumen del mecanismo de ancho de banda de la zona de control de acceso

Criterios de evaluación  Valor 

Compatible con VoX

Sólo VoIP/H.323

Conexión troncal/Telefonía IP

  • Conexión troncal y telefonía IP
  • Algunas advertencias si tanto el administrador de llamadas como las puertas de enlace de Cisco IOS se usan en la misma zona.

Plataforma/Versión

  • Puertas de enlace de Cisco IOS a partir de la versión 11.3
  • CM ha incorporado cambios recientes en el registro de E.164 y el ancho de banda solicitado por llamada.

Tipos de troncal PBX compatibles

Todos

Extremo a extremo/Local/nube IP

Extremo a extremo entre la puerta de enlace saliente y la de terminación aunque no es consciente de la topología de red (disponibilidad de ancho de banda) en medio.

Por llamada/interfaz/punto final (endpoint)

Por llamada

Reconocimiento de topología

Ninguno

Garantías de calidad del servicio durante la llamada

Ninguna

Retraso posterior al marcado

Ninguno

Tara de mensajería de red

Parte de la mensajería RAS del control de acceso

Protocolo de reserva de recursos

RSVP es el único mecanismo de CAC que realiza una reserva de ancho de banda y que no toma una decisión de admisión de llamada basada en la mejor suposición antes de configurar la llamada. De esta forma se proporciona a RSVP la ventaja exclusiva de no sólo ofrecer el CAC para la voz sino también garantizar la calidad del servicio frente a condiciones de la red cambiantes durante la llamada.

Desarrollo de características de RSVP

RSVP se sincroniza con la máquina de estado H.323 en la versión 12.1(5)T de Cisco IOS y, por lo tanto, está disponible en la versión 12.2. En versiones anteriores del software podrá encontrar varios componentes de esta característica, pero todos los elementos para el CAC recién estuvieron disponibles en la versión 12.1(5)T. A continuación, podrá encontrar un breve resumen sobre la compatibilidad con RSVP:

  • RSVP sincronizado con la conexión estándar de H.323: versión 12.1(1)T
  • Compatible con RSVP para LLQ: versión 12.1(3)T
  • Sincronización de RSVP con el procedimiento de conexión rápida de H.323: versión 12.1(5)T
  • Compatible con RSVP para FR PVC: versión 12.1(5)T

En futuras versiones de software se introducirá soporte de RSVP para ATM PVC y en los teléfonos IP.

Reserva de RSVP para una llamada de voz

En la figura 21 se muestra un flujo de llamada de los mensajes de configuración de llamadas H.323 y los mensajes de reserva de RSVP.


Figura 21   Configuración de llamada RSVP para la llamada de voz de H.323


La configuración de H.323 se suspende antes de que el teléfono de destino, activado mediante el mensaje de alerta de H.225, comience a sonar. La reserva de RSVP se realiza en ambas direcciones porque la llamada de voz necesita una ruta de conversación en dos direcciones y, por lo tanto, ancho de banda en ambas. Finalmente, la puerta de enlace de terminación toma la decisión de CAC basándose en si ambas reservas tienen éxito. En ese punto, la máquina de estado de H.323 continúa con una alerta/conexión de H.225 (se permite la llamada y se procesa) o con un rechazo/liberación de H.225 (se deniega la llamada). La resera de RSVP se habrá efectuado en el momento en el que el teléfono de destino comience a sonar y la persona que llama oiga el tono de llamada.

RSVP se diferencia de otros métodos de CAC tratados en este documento en los siguientes aspectos:

  • La posibilidad de mantener la calidad de servicio durante la llamada.
  • Reconocimiento de la topología. De hecho, la reserva de RSVP se instala en cada interfaz que la llamada atraviese por la red (en secciones posteriores, se tratarán algunas excepciones a este hecho) y, por lo tanto, se garantiza el ancho de banda en cada segmento sin que sea necesario saber el ancho de banda real de una interfaz ni la ruta por la que los protocolos de enrutamiento dirigirán los paquetes. (Por lo tanto, RSVP ajustará automáticamente los cambios de configuración de red con lo que no serán necesarios cálculos manuales para mantener los distintos aspectos de la configuración sincronizados.)

RSVP es una reserva de extremo a extremo por llamada y sólo tiene visibilidad para ella. No es consciente de la cantidad de llamadas activas de un sitio o a través de una interfaz ni del origen ni el destino de cualquier otra llamada. Así que no hay forma de configurar los niveles totales de CAC con RSVP, como el CAC de sitio a sitio que podemos hacer con el control de ancho de banda de la zona de control de acceso.

Clasificación para paquetes de voz en LLQ

LLQ es uno de los mecanismos importantes de calidad de servicio de Cisco para garantizar la calidad de la voz ya que prioriza los paquetes de voz frente a los de datos en la interfaz de salida del router. Para que esto funcione, los paquetes de voz deben clasificarse de manera que se coloquen en la parte de la cola de prioridad (PQ, Priority Queue) de LLQ. Por lo general, se realiza con la clasificación de la lista de control de acceso (ACL, Access Control List), en la que los puertos TCP (señalización) y UDP (medios) coinciden para canalizar los paquetes de voz en las colas apropiadas.

Como característica general de Cisco IOS, RSVP tiene su propio conjunto de colas reservadas en la colocación en cola equilibrada ponderada (WFQ, Weighted Fair Queueing) para el tráfico con reservas de RSVP. Aunque estas colas tengan poco peso, están separadas de la PQ. Los paquetes en colas reservadas no tienen prioridad sobre paquetes de otras colas salvo por el bajo peso. Se sabe desde hace tiempo que este tratamiento (una cola de peso bajo dentro de WFQ) es insuficiente para garantizar la calidad de la voz en una interfaz sobrecarga con distintos flujos de tráfico. Por lo tanto, cuando se configura RSVP para una llamada de voz, es necesario clasificar los paquetes de voz en la PQ. Los paquetes de flujo de datos de RSVP no deberían clasificarse en la PQ en este caso.

RSVP utiliza un perfil para determinar si un flujo de paquetes es de voz. El perfil considera los tamaños de los paquetes, las velocidades de llegada, además de otros parámetros. Se considera un flujo de voz un flujo de paquetes que se ajuste a ellos. Si no, será un flujo que no es de voz, sino que puede ser tanto de datos como de video. El perfil interno se ajusta de manera que todo el tráfico de voz que se origine a partir de una puerta de enlace de Cisco IOS se incluirá dentro de los parámetros y será considerado, por lo tanto, un flujo de voz sin que sea necesaria una configuración adicional. En el caso de aplicaciones de terceros, como NetMeeting, es posible que sea necesario ajustar el perfil para recoger este tipo de tráfico. En la figura 22 se muestra cómo se lleva a cabo.


Figura 22   Criterios de clasificación de paquetes de RSVP


RSVP es el primer clasificador de la interfaz de salida que examina los paquetes que llegan. Si RSVP considera que el paquete es un flujo de voz, lo colocará en la parte del PQ de LLQ. Si el flujo no se ajusta al perfil de voz, pero es, sin embargo, un flujo de RSVP reservado, se colocará en las colas reservadas normales de RSVP. Si el flujo no es un flujo de voz ni de datos de RSVP, los otros identificadores de la interfaz de salida (como las ACL y las declaraciones de coincidencia dentro de un mapa de clases) intentarán clasificar el paquete para colocarlo en la cola.

Es importante tener en cuenta que RSVP clasificará sólo el tráfico portador de voz, no de señalización. Se deberá seguir utilizando uno de los otros mecanismos de clasificación, como las ACL o los DSCP, para clasificar el tráfico de señalización de voz si se desea un tratamiento más adecuado que el mejor esfuerzo para ese tráfico. Si la decisión se deja sólo a RSVP, el tráfico de señalización se considerará como el tráfico del mejor esfuerzo tal y como se muestra en la figura 22.

Asignación de ancho de banda con RSVP y LLQ

El tráfico de voz de RSVP puede mezclarse con el tráfico de "clase de prioridad" (dentro de la asignación de políticas) en la PQ, pero la configuración es más sencilla si se utiliza un único mecanismo de clasificación de voz. Por lo tanto, recomendamos que use una u otra configuración para la voz, pero no ambas. Configure RSVP para dar prioridad al tráfico de voz o configure la asignación de políticas con el ancho de banda de prioridad y clasifique el tráfico de voz con ACL en LLQ. Ambas pueden usarse a la vez pero no comparten las asignaciones de ancho de banda y, por lo tanto, llevarán a un uso ineficaz del ancho de banda en la interfaz.

Como el ancho de banda se define en la configuración para las interfaces de salida, se asignará ancho de banda a las clases de ancho de banda y de prioridad en el momento de la configuración. No se asignará ancho de banda a RSVP en este momento, sino que se solicitará ancho de banda cuando el flujo de tráfico comience (cuando comience la llamada de voz). Por lo tanto, RSVP obtiene ancho de banda desde la agrupación que queda una vez que ya se haya asignado el ancho de banda a las otras características.

Ancho de banda por códec

Tanto LLQ como RSVP ven el paquete IP de capa 3. Las encapsulaciones de la capa 2 (FR, MLPPP, etc.) se añaden después de la colocación en cola de manera que el ancho de banda asignado tanto a LLQ como a RSVP para una llamada se basa en el ancho de banda de la capa 3 de los paquetes. Este número será ligeramente diferente del ancho de banda real utilizado en la interfaz una vez que se hayan incorporado los encabezados y las colas de la capa 2. El ancho de banda RSVP reservado para una llamada también excluye tanto cRTP como VAD. En la tabla 15 se resume el ancho de banda que RSVP asignará a las llamadas usando distintos códecs de la puerta de enlace de Cisco IOS.

Tabla 15   Reservas del ancho de banda de RSVP para los códecs de voz

Códec  Ancho de banda reservado por llamada en LLQ 

G.711 (a-law y m -law)

80 kbps

G.723.1 y G.723.1A (5,3 kbps)

22 kbps

G.723.1 y G.723.1A (6,3 kbps)

23 kbps

G.726 (16 kbps)

32 kbps

G.726 (24 kbps)

40 kbps

G.726 (32 kbps)

48 kbps

G.728

32 kbps

G.729 (todas las versiones)

24 kbps

Configuración de RSVP

Realice las siguientes tres tareas en una puerta de enlace para originar o terminar el tráfico de voz usando RSVP:

  • Active la característica de sincronización entre RSVP y H.323. Existe un comando global y se activa en forma predeterminada cuando se carga la versión 12.1(5)T o posterior de Cisco IOS.
  • Configure RSVP tanto en los lados de origen como de terminación de los pares de marcado de VoIP. Configure tanto la calidad de servicio solicitada (req-qos) como la calidad de servicio aceptable (acc-qos) del comando guaranteed-delay para RSVP a fin de que actúe como un mecanismo de CAC. (Otras combinaciones de parámetros pueden llevar a una reserva, pero sin CAC.)
  • Active el RSVP y especifique el ancho de banda máximo en las interfaces que la llamada atravesará.

El siguiente ejemplo de configuración activa RSVP:

!Comando global que activa RSVP como CAC, activado de forma predeterminada.
call rsvp-sync
controller T1 1/0
 ds0-group 0 timeslots 1-24
!
!Perfil de clasificación de RSVP; el valor predeterminado es "ok" 
! para todo el tráfico de voz de la puerta de enlace de Cisco IOS.
ip rsvp pq-profile voice-like
!
voice-port 1/0:0
!         
dial-peer voice 100 pots
 destination-pattern 2......
port 1/0:0
!         
dial-peer voice 300 voip
 destination-pattern 3......
session target ipv4:10.10.2.2
!Configura CAC de RSVP para llamadas de voz usando el par de marcado.
req-qos guaranteed-delay
 acc-qos guaranteed-delay

El siguiente ejemplo de configuración activa RSVP en una interfaz de PPP:

interface Serial0/1
 bandwidth 1536
 ip address 10.10.1.1 255.255.255.0
 encapsulation ppp
!Activa WFQ como el método de colocación en cola básico. Resulta en LLQ con RSVP.
fair-queue 64 256 36
!Activa RSVP en la interfaz.
ip rsvp bandwidth 1152 24

El siguiente ejemplo de configuración activa RSVP para una interfaz de Frame Relay:

interface Serial0/0
 bandwidth 1536
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!         
interface Serial0/0.2 point-to-point
 ip address 10.10.2.2 255.255.255.0
 frame-relay interface-dlci 17   
  class VoIPoFR
!Activa RSVP en la subinterfaz.
ip rsvp bandwidth 64 24
map-class frame-relay VoIPoFR
 no frame-relay adaptive-shaping
 frame-relay cir 128000
 frame-relay bc 1280
 frame-relay mincir 128000
!Activa WFQ como el método de colocación en cola básico. Resulta en LLQ con RSVP.
frame-relay fair-queue
 frame-relay fragment 160

Escalabilidad de RSVP

Con frecuencia se expresa cierta preocupación sobre la escalabilidad de RSVP en relación con la gran cantidad de reservas de flujo individuales que pueden ser necesarias en los enlaces de estructura básica de alta velocidad allí donde se hayan agregado muchas llamadas de voz. De hecho, es posible que no tenga sentido hacer la gestión de flujo individual sobre los enlaces de red de estructura básica OC-12, por ejemplo. Por esta razón, en la versión 12.1(5)T del código de Cisco IOS y en versiones posteriores, si no se ha configurado RSVP en ninguna interfaz de una plataforma, los mensajes de RSVP pasarán de forma transparente. No se realiza ni se gestiona ninguna reserva, aunque ni la ruta ni los paquetes Resv se eliminan.

Esto hace posible crear topologías híbridas en la que se usa RSVP alrededor de los bordes de la red para proteger los enlaces de acceso WAN más lentos del exceso de suscripciones mientras que las oficinas centrales de alta velocidad y los enlaces de estructura básica de WAN no usan RSVP. Por supuesto, esta topología compromete la verdadera reserva de extremo a extremo y la promesa de RSVP de calidad de servicio garantizada, aunque es un compromiso que puede asumirse. Los enlaces de la estructura básica pueden recibir una medida de protección de la manipulación excesiva o de uno de los otros mecanismos de CAC tratados anteriormente, mientras que los enlaces de contención más elevados (normalmente el borde de WAN) pueden hacer uso de RSVP.

En la figura 23 se muestra una red hipotética que está configurada para DiffServ en la estructura básica y las oficinas centrales, pero que utiliza las reservas de RSVP en los enlaces de borde de WAN.


Figura 23   Topología de red híbrida de DiffServ/RSVP


Resumen del protocolo RSVP de CAC

Recuerde los siguientes factores con respecto al uso de RSVP como un mecanismo de CAC:

  • En el software Cisco IOS actual, las llamadas de H.323 se inician en forma predeterminada usando la conexión rápida cuando se configura RSVP.
  • Los paquetes RSVP (PATH y RESV) viajan como tráfico de mejor esfuerzo.
  • WFQ debe activarse en una interfaz/PVC como base para LLQ.

RSVP sólo es un mecanismo de CAC verdadero de extremo a extremo si está configurado en cada interfaz que atraviesa una llamada.

Debido a la función única de servir como un mecanismo de CAC de extremo a extremo y garantizar la calidad de servicio durante toda la llamada, RSVP incurre en algunos "costos" en la red, tal y como se describe a continuación:

  • Señalización (mensajería y procesamiento).
  • Por estado de flujo (memoria).
  • Retrasos posteriores al marcado.
  • RSVP no ofrece la posibilidad de redirección de llamada después de la configuración de llamada si un enlace en la red fallara.
  • Los teléfonos IP de Cisco aún no son compatibles con RSVP.

En la tabla 16 se evalúa el mecanismo de RSVP frente a los criterios de evaluación de CAC descritos anteriormente en este documento.

Tabla 16   Resumen del mecanismo de RSVP

Criterios de evaluación  Valor 

Compatible con VoX

Sólo VoIP/H.323

Conexión troncal/Telefonía IP

Sólo conexión troncal

Plataforma/Versión

Puertas de enlace de Cisco IOS en las versiones 12.1(5)T y 12.2

Tipos de troncal PBX compatibles

Todos

Extremo a extremo/Local/nube IP

  • Extremo a extremo entre la puerta de enlace saliente y el control de acceso de terminación (siempre que todos los nodos intermedios estén configurados para RSVP).
  • Podría usarse en el borde de WAN con la estructura básica de DiffServ.

Por llamada/interfaz/punto final (endpoint)

Por llamada

Reconocimiento de topología

Garantías de calidad del servicio durante la llamada

Retraso posterior al marcado

Tara de mensajería de red

PATH/RESV y mantenimiento periódico

Cómo aplicar CAC a la red

Aunque hay superposición entre la funcionalidad que los diferentes mecanismos de CAC ofrecen, también hay varios de ellos que resuelven distintos aspectos del problema de CAC y, por lo tanto, tendría sentido usarlos juntos en un diseño de red. Con frecuencia, surgen las siguientes preguntas:

  • ¿Se pueden usar dos métodos de CAC juntos en la misma puerta de enlace, al mismo tiempo y para las mismas llamadas?
  • (Si la respuesta a esta pregunta es sí.) ¿En qué secuencia se llega a la decisión de CAC?

En la figura 24 se resume la secuencia de las características de CAC que pueden estar activas en la puerta de enlace saliente, basada en las versiones 12.1(5)T y 12.2 de Cisco IOS. Conforme cambian las características y las versiones del software y se solucionan los errores de funcionamiento, es posible que esta información cambie sin previo aviso. Tal y como muestra el diagrama de flujo, las únicas características que se excluyen mutuamente son RSVP y el repliegue de PSTN.


Figura 24   Secuencia de la utilización de características de CAC en una puerta de enlace saliente


En las siguientes secciones se describe cómo podemos implementar los mecanismos de CAC:

Cuándo y qué mecanismo de CAC utilizar

Con la cantidad ingente de mecanismos de CAC disponibles, la siguiente pregunta de diseño es: ¿cuándo y qué característica de CAC debería usar? Tal y como se ha puesto de relieve durante las descripciones de las características individuales y gracias a las comparaciones y resúmenes que se han descrito en el texto, es frecuente que las distintas características hagan cosas diferentes y resuelvan distintos aspectos de un problema de CAC. Algunos de estos aspectos pueden ser criterios de diseño más importantes para la red que otros. De este modo, no hay una única receta que prescribe exactamente cuándo usar qué mecanismo. Tal y como ocurre con otras características de software, debe tomar la decisión mientras considera sus objetivos del diseño de la red.

Esta sección intenta ofrecer algunas ideas sobre los criterios de diseño que pueden existir para la red y, si es así, qué características pueden ajustarse a la solución. Los criterios de selección de características que deberían usarse primero son los "criterios de evaluación" enumerados al final de cada sección de características descrita anteriormente. Por ejemplo, si se está diseñando una red de VoIP basada en SIP, no sirve de nada considerar una característica de CAC de H.323. Siempre que haya llevado a cabo ese nivel de monitoreo, utilice las sugerencias de esta sección para seguir restringiendo la elección de características.

CAC en redes troncales de conexión

A diferencia de las redes conmutadas, donde cada llamada se configura de forma individual a través de la red de paquete después de que un usuario marque, las redes de "troncal de conexión" consisten en conexiones constantes a través de la red de paquete. El PBX puede percibir que realiza cada llamada de manera individual, pero la red de paquete tiene un troncal permanente colocado (un enlace de punto a punto similar en concepto al de una línea alquilada) que está siempre presente, siempre listo y siempre termina en un destino fijo y predeterminado. Estas configuraciones de red de paquete constante se usan normalmente cuando la señalización está presente entre los PBX y debe pasar de forma transparente y sin sufrir cambios a través de la red de paquete. Las puertas de enlace no pueden interpretar la señalización, así que simplemente la pasan a través de la red de paquete.

Existen dos aplicaciones principales para este tipo de red tal y como se describe a continuación:

  • Redes en las que la señalización como las de colgado rápido y las indicaciones de mensaje en espera (MWI, Message Waiting Indications) deben pasar a través de la red de paquete hacia un PBX para que se activen para teléfonos OPX (Off Premise Extension, Extensión de premisa de apagado). Estos teléfonos están separados por la red de paquete del PBX desde el que envían sus características.
  • Redes en las que la señalización de propiedad se utiliza entre los PBX para activar las características de conexiones de redes PBX privadas. (Los ejemplos incluyen Lucent DCS, Siemens CorNet y NEC CCIS.)

Las configuraciones del troncal de conexión de la puerta de enlace de Cisco IOS utilizan las mismas herramientas básicas (como los pares de marcado) que las redes conmutadas para configurar conexiones. La diferencia es que estas "llamadas" sólo se configuran una vez, cuando se inicia la puerta de enlace o cuando se inserta la configuración y permanece de manera indefinida. Si falla un enlace en la red y la llamada se interrumpe, el router la restablecerá en cuanto pueda. Si en realidad hay una llamada real activa (con una conversación en curso) en esta conexión, es algo transparente para las puertas de enlace. Por esta razón, los mecanismos de CAC estándar, en la mayoría de los casos, no se aplican. Las configuraciones del troncal de conexión no aparecerán de forma adecuada si no hay suficiente ancho de banda para la conexión. Así que una vez que se haya configurado, debería haber suficiente ancho de banda disponible para las llamadas.

Los siguientes mecanismos de CAC de llamada por llamada sólo se aplican a redes conmutadas y no deberían usarse con las configuraciones del troncal de conexión:

Las configuraciones del troncal de conexión podrán, sin embargo, beneficiarse de las características del estado ocupado de CAC del PBX. Cuando algo no está conectado en la red y las conexiones permanentes o las interfaces que se usan fallan, sería ciertamente útil que se enviara una señal de ocupado del troncal al PBX. Estas características son las siguientes:

De hecho, RSVP podría usarse para garantizar (reservar) el ancho de banda para las llamadas constantes con el fin de proteger la calidad de la voz de las condiciones de red fluctuantes. Sin embargo, puesto que las redes del troncal de conexión están fijas (conexiones de punto a punto), la cantidad de llamadas activas en cualquier segmento de la red (desde la perspectiva del router) es fija y es relativamente fácil de diseñar cambiando la ingeniería del ancho de banda manualmente y usando configuraciones LLQ estándar para garantizar el ancho de banda. Debería considerar si RSVP sería útil en dicha situación.

Áreas de la red que proteger

Los métodos de CAC son más útiles y necesarios en redes conmutadas donde, con frecuencia, es imposible predecir exactamente cuántas llamadas podría querer hacer para usar un tramo de red concreto en un momento determinado. Los métodos estadísticos para la ingeniería de redes de voz han existido durante décadas. No obstante, no hay ningún mecanismo para saber exactamente quién llamará a quién a través de la red en un momento determinado. A menos que la topología de la red sea muy simple, es posible que el ancho de banda en algún punto de la red tenga exceso de suscripciones de demasiadas llamadas. En la PSTN, esta condición da como resultado un tono de reorden o un mensaje de interceptación que informa que "todos los circuitos están ocupados".

Cuando se consideren los métodos de CAC para activar una condición comparable con aquella en la que "todos los circuitos están ocupados" si una red de paquete está demasiado sobrecargada para llevar una llamada, tenga en cuenta también los objetivos del diseño de la red. Todos los aspectos del CAC mostrados en la figura 25 existen en cada red, pero hay algunos atributos que serán casi siempre más importantes para un cliente particular que para otros. Los aspectos de la red que pueden necesitar protección con las características de CAC se han dividido en cuatro áreas (A, B, C y D), tal y como se muestra en la figura 25.


Figura 25   División de las áreas de la red


El área A es la conexión POTS de origen. Si es importante evitar que el PBX de origen intente realizar una llamada a la red de paquete cuando ésta sea incapaz de completar la llamada, entonces deberían tenerse en cuenta las características de CAC de estado ocupado. Esto puede ser importante si la devolución de llamada es un método de recuperación de rechazo de llamada inaceptable o si el sistema PBX/Key no cuenta con la posibilidad de elegir otra ruta para una llamada rechazada o devuelta.

El área B es el lado POTS de terminación de la conexión. Si es probable debido a los patrones de tráfico específicos que el lado POTS de terminación sea la parte de la red más susceptible de tener exceso de suscripciones, entonces debería usarse el RAI de control de acceso. En las redes de empresa, esto apenas tiene importancia. Sin embargo, en las redes de proveedores de servicio, se trata con frecuencia de una sección extremadamente importante de la red que hay que proteger.

El área C es la parte de la estructura básica de IP de la red. Se trata del área más típica de la red de paquete contra la que los clientes de empresa (incluso las redes de servicios administrados de proveedores de servicio) desean proteger sus llamadas ya que esta infraestructura no está dedicada a la voz sino que la comparten muchos tipos de tráfico. Las características de CAC que protegen la "nube" de red son las siguientes:

Estos métodos de CAC son todos métodos basados en IP lo que significa implícitamente que hay más métodos de CAC disponibles para las redes VoIP que para las redes VoFR y VoATM. Además, las redes VoIP necesitan el CAC mucho más porque las tecnologías de la capa 2, como retransmisión por frame (frame relay) y ATM, no se pueden proteger intrínsecamente contra la pérdida de paquetes de VoIP, algo que sí pueden hacer con el tráfico de VoFR y VoATM.

El área D es una sección lógica de la red entre sitios. Sin tener en cuenta la infraestructura real que conecta los sitios, puede querer no limitar el tráfico dentro de un sitio o limitarlo basándose en criterios diferentes de las limitaciones de tráfico entre los sitios. Por ejemplo, si la ubicación de las oficinas principales puede manejar 24 llamadas activas de una vez, es posible que desee asegurarse de que no puedan ser usadas por ningún otro sitio en ningún momento, pero que quede una parte de capacidad disponible para sitios remotos diferentes de manera que los sitios con poco tráfico no se queden bloqueados por los sitios con mucho tráfico.

Las características de CAC que usaría en esta situación serían las siguientes:

Consideraciones de la topología de red

En términos generales, existen dos topologías de red que considerar de la siguiente manera:

  • Hub y radio
  • Red jerárquica de varias capas con capas de distribución

Estas dos topologías se muestran de forma conceptual en la Figura 26.


Figura 26   Topologías de red de empresa


La red de hub y radio es más fácil de mantener. En este caso, la mayoría de las características de CAC son útiles porque sólo los radios de la red necesitan protección. No hay una estructura básica invisible y los enlaces de radio podrían ser los enlaces conectados a las puertas de enlace en los sitios remotos. Casi ninguna de las siguientes características del CAC podrían usarse para producir un buen efecto en este tipo de red:

La red jerárquica de varias capas es más representativa de redes más grandes donde los sitios periféricos se agregan a una o varias capas de los puntos intermedios antes de una red de núcleo que conecta los sitios de agrupación de las capas más altas. Muchas de las características de CAC protegerán el enlace WAN en la capa más baja de la red, pero pocas de ellas tendrán visibilidad dentro de la agrupación y los tramos del núcleo de la red. Las características con visibilidad dentro de la red son las siguientes: