MXPA03004669A - Interfase de control y reporte de mensajes para un sistema de acceso en red distribuida. - Google Patents

Abstract

Un sistema de acceso en red incluye un procesador externo y un dispositivo de acceso programable (PAD) (40a, 40b). El procesador externo (42) transmite un mensaje de control a PAD (40a, 40b) para establecer una configuracion de PAD. PAD entonces comunica mensajes al procesador externo (42) para el procesamiento de servicio de acuerdo con la presente configuracion. Para limitar la comunicacion de los mensajes de red desde PAD al procesador externo, PAD puede enviar un mensaje configurando las banderas de la interface de mensajes en PAD. El procesador externo tambien puede transmitir un mensaje de control de monitoreo a PAD para establecer una configuracion de un monitor en PAD. Entonces PAD, comunica mensajes de reporte al procesador externo en respuesta a la configuracion del monitor.

Description

INTERFASE DE CONTROL Y REPORTE DE MENSAJES PARA UN SISTEMA DE ACCESO EN RED DISTRIBUIDA ANTECEDENTES DE LA INVENCION 1. Campo Técnico La presente invención se refiere en general a redes de comunicaciones y, en particular, a una red de comunicación de IP céntrica. Aún más particularmente, la presente invención se refiere a una red de comunicación basada en la IP incluyendo un sistema de acceso en red que tiene direccionamiento distribuido y separado, señalización, control de servicio, filtración, control de políticas y otras funcionalidades a partir del envío de la IP. 2. Descripción de la Técnica relacionada El Internet puede por lo general ser definido como una colección mundial de redes de comunicaciones heterogéneas y compuertas, puentes y direccionadores asociados que todos emplean el grupo de protocolos TCP/IP (Protocolo de Control de Transporte/Protocolo Internet) para comunicar paquetes de datos entre una fuente y uno o más destinos. Como es bien conocido por aquellos con experiencia en la técnica, el grupo de protocolos TCP/IP corresponde a las capas 3 y 4 (las capas de red y de transporte, respectivamente) del modelo de referencia de siete capas de la Organización para la Interconexión de sistemas Abiertos de Estandarización (ISO/OSI), el cual proporciona un marco de trabajo conveniente para discutir los protocolos de comunicación. El modelo de referencia ISO/OSI además incluye capas físicas y de enlace (capas 1 y 2, respectivamente) por debajo de la red y capas de transporte, y capas de sesión, presentación, y aplicación (capas 5 a 7, respectivamente) por arriba de la red y capas de transporte. La Figura 1A ilustra una vista de nivel metropolitana de una red de Proveedor de Servicio de Internet (ISP) 10 a través de la cual los clientes pueden accesar el Internet. Iniciando a partir de lado izquierdo, muchas interfases de Redes de Área Local (LANs) 14 de cliente a la red ISP 10 a través de una variedad de redes de acceso metropolitano 16, que emplean cualquiera de un número de tecnologías de red; por ejemplo, Multiplexando la División del Tiempo (TDM), Modo de Transferencia Asincrónico (ATM), y Ethernet. Además, ya que es típico en grandes áreas metropolitanas, existen muchos niveles de jerarquía en las redes de acceso metropolitanas 16, con múltiples anillos conectando a cada cliente a un sitio de agregación y múltiples sitios de agregación del nivel más bajo alimentando un sitio de agregación de nivel más alto. Típicamente, solamente deben existir unos pocos de sitios de agregación en donde los direccionadores de agregación 12 son desplegados en un área metropolitana. La Figura 1A muestra solamente uno de dichos sitios de agregación 17. Todo el tráfico de una LAN cliente 14 es transportada de regreso a través de estas redes de agregación a este sitio de agregación 17, en donde los direccionadores de agregación 12 aplican el tratamiento de manejo de políticas tal como políticas, marcación y control de admisión. Los direccionadores de agregación entonces direccional el tráfico ya sea de regreso a otra LAN cliente 14, o de otra manera al direccionador núcleo 18 para la transmisión a través del núcleo 20 a algunos de los destinos más distantes. El estado de la técnica en el diseño de direccionadores a una gran extensión dicta el diseño de red mostrado en la Figura 1A debido a que los direccionadores son costosos y deben operar sobre flujos de tráfico altamente agregados. Una consideración principal en el diseño de dichas redes es minimizar el número de direccionadores, para que el protocolo de direccionamiento haga la escala efectivamente. Esto significa que un número de funciones son concentrados en estos direccionadores: direccionamiento, almacenamiento de base de datos de políticas, y ejecución de políticas. En la técnica anterior, la arquitectura del direccionador es generalmente monolítica y propietaria. Consecuentemente, la escala de los servicios de datos que un proveedor de servicios puede ofrecer además del direccionamiento del paquete básico está limitada por el software de control ofrecido por los vendedores de direccionadores. Además, el rendimiento del procesamiento de paquetes de un direccionador está generalmente limitado por su hardware de procesamiento originalmente instalado y no puede ser expandido o extendido sin reemplazar el direccionador completo. El diseño monolítico y de propietario de direccionadores convencionales presenta un número de problemas dirigidos a través de la presente invención. Primero, debido a que los direccionadores trad icionalmente tiene un controlador individual proporcionando todos los servicios para todos los tipos de mensajes, los controladores de direccionador de borde tienden a ser muy complejos, haciendo difícil y costos agregar nuevos servicios o modificar los servicios existentes. Como un resultado, el tiempo para comercializar nuevos servicios basados en un direccionador está extendido y usualmente depende de los vendedores respondiendo a las solicitudes de los proveedores del servicio para implementar nuevos dentro de sus arquitecturas de direccionadores propietarios. Segundo, las arquitecturas de direccionador monolíticas convencionales no son fácilmente escalables, lo cual presenta un problema importante para los proveedores de servicios, particularmente en luz del crecimiento fenomenal del tráfico en Internet. Consecuentemente, las capacidades de procesamiento de direccionadores destacados no pueden ser fácilmente escaladas para mantener el paso con el tráfico ¡ncremental. En su lugar, los proveedores de servicios deben comprar direccionadores adicionales o reemplazarlos para lograr las demandas del tráfico incrementado. Tercero, los diseños de direccionadores monolíticos convencionales también tienen una flexibilidad y extensibilidad limitada. Por ejemplo, la presente invención reconoce que serla deseable, en vista del rápido crecimiento del tráfico en Internet, a dinámicamente provisionar, configurar y/o reasignar capacidad de acceso a servicios con base en IP. Debido a que la capacidad de acceso es necesariamente limitada y proporcionar capacidad de acceso adicional es un componente de costo mayor de redes, la ejecución de políticas de control de admisión inteligente y provisión de diferentes cualidades de servicio es vital para la utilización eficiente de capacidad de acceso disponible. Sin embargo, los direccionadores de borde convencionales no son capaces de clasificar una amplia variedad de tipos de tráfico mientras que los controles de políticas o de respuesta a solicitudes dinámicas para capacidad, y esta funcionalidad es difícil de incorporar en los direccionadores de borde monolíticos desplegados. La presente invención por consiguiente reconoce que sería deseable proporcionar lo anterior así como un control de políticas adicional, monitoreo de red, diagnóstico y servicios de seguridad en hardware comercializado mientras estos servicios serán personalizados para cumplir con las necesidades de clientes individuales y proveedores de servicios. Cuarto, debido a la naturaleza de propiedad de las arquitecturas de direccionador y servicios, si un proveedor de servicio despliega direccionadores desde múltiples vendedores en una red de comunicación, los servicios de propiedad implementados por los vendedores de direccionadores diferentes no necesariamente operarán entre ellos. Consecuentemente, los proveedores de servicios no son capaces de comprar direccionadores y conmutadores de un vendedor, y comprar software de control de servicio de otro vendedor. Además, un proveedor de servicio no puede ofrecer su red de comunicación como una plataforma para un proveedor mayorista para ofrecer servicios de datos de valor agregado utilizando las capacidades de red base existentes. En vista de las limitaciones anteriores y adicionales en la técnica anterior, la presente invención reconoce que serla deseable introducir una nueva arquitectura de acceso a la red que dirija y supere las limitaciones de las arquitecturas de direccionador monolítico convencionales.

COMPENDIO DE LA INVENCION La presente invención introduce una arquitectura de sistema de acceso en red distribuida incluyendo por lo menos un procesador externo y un dispositivo de acceso programable. En una modalidad preferida, el sistema de acceso en red además incluye un direccionador de acceso acoplado al dispositivo de acceso programable. De acuerdo con la presente invención, el procesador externo transmite un mensaje de control al dispositivo de acceso programable para establecer una configuración del dispositivo de acceso programable. El dispositivo de acceso programable entonces comunica mensajes al procesador externo para procesamiento del servicio de acuerdo con la configuración. Por ejemplo, el mensaje de control puede ser un mensaje de control de filtro que establece una configuración de un filtro de encabezado de paquete en el dispositivo de acceso programable. El filtro de encabezado de paquete entonces comunica mensajes de red filtrados desde un flujo de paquete de acuerdo con la configuración establecida por el mensaje de control. Para limitar la comunicación de los mensajes de red desde el dispositivo de acceso programable al procesador externo, el dispositivo de acceso programable puede enviar un mensaje configurando las banderas de la inferíase del mensaje en el dispositivo de acceso programable. El procesador externo también puede transmitir un mensaje de control de monitor al dispositivo de acceso programable para establecer una configuración de un monitor en el dispositivo de acceso programable. El dispositivo de acceso programable entonces comunica mensajes de reporte al procesador externo en respuesta a la configuración del monitor. De esta manera, de acuerdo con la presente invención, los direccionadores de borde propietarios, monolíticos convencionales son reemplazados con un sistema de acceso de red distribuida que asigna la funcionalidad de los direccionadores de borde tradicionales (asi como funcionalidad adicional) entre tres módulos lógicos: un dispositivo de acceso programable, un procesador externo y un direccionador de acceso. De acuerdo con una modalidad preferida de la presente invención, el direccionamiento básico de paquetes entre puertos de entrada y salida de la red de acceso es llevado a cabo por el d ireccionador de acceso. Sin embargo, las funciones de enviar y condicionar el tráfico genérico, tal como marcación, políticas, monitoreo, configuración y filtrado, son implementadas en el dispositivo de acceso programable, y las funciones de servicio, tal como interpretación de mensajes, señalización, control de admisión e invocación de políticas, son implementadas en el procesador externo. Como se detalla más adelante, esta distribución de funcionalidad da como resultado numerosas ventajas, incluyendo escalamiento mejorado, flexibilidad, extensibilidad, interoperabilidad, seguridad y provisionamiento de servicios. Los objetos, características y ventajas adicionales de la presente invención serán aparentes en la siguiente descripción escrita detallada.

BREVE DESCRIPCION DE LOS DIBUJOS Los aspectos novedosos consideran que las características de la invención están establecidas en las reivindicaciones anexas. La invención por sí misma sin embargo, así como un modo preferido de uso, objetos adicionales y ventajas del mismo, se entenderán mejor mediante la referencia a la siguiente descripción detallada de una modalidad ilustrativa cuando se lee en conjunción con los dibujos que la acompañan, en donde: La Figura 1A es una vista metropolitana de una red de proveedor de servicio de Internet de la técnica anterior conteniendo direccionadores de agregación y núcleo; La Figura 1B es una vista metropolitana de una red de proveedor de servicio de Internet de acuerdo con la presente invención; La Figura 2 descrie una modalidad ilustrativa de una red de comunicación de acuerdo con la presente invención; La Figura 3 es un diagrama de bloque más detallado de una modalidad ilustrativa de un dispositivo de acceso programable (PAD) de acuerdo con la presente invención; La Figura 4 es un diagrama de bloque más detallado de una modalidad ilustrativa de un procesador externo de acuerdo con la presente invención; La Figura 5A ilustra la señalización ilustrativa entre un dispositivo de acceso programable y un procesador externo durante la conmutación a un controlador de servicio secundario debido a una falla del controlador de servicio primario; La Figura 5B describe la señalización ilustrativa entre un dispositivo de acceso programable y un procesador externo durante una conmutación desde un controlador de servicio secundario a un controlador de servicio primario después de la restauración del controlador de servicio primario; La Figura 6 ilustra la señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para reservación de servicios de soporte utilizando Protocolo de Reservación de Recursos (RSVP); La Figura 7A es un diagrama de máquina específico ilustrando la operación de un dispositivo de acceso programable ilustrativo durante una sesión TCP; La Figura 7B es un diagrama ilustrando la operación de un dispositivo de acceso programable ilustrativo y controlador de servicio asociado en el caso de una condición completa de memoria específica TCP; La Figura 7C describe la señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención durante el establecimiento de la sesión TCP; La Figura 7D ilustra la señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención durante la desconexión de una sesión TCP; La Figura 7E describe señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a una solicitud autorizada para una sesión TCP; La Figura 7F ¡lustra la señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención cuando una sesión TCP se desconecta; La Figura 7G describe la señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención cuando una sesión TCP se cierra abruptamente; La Figura 8A ilustra la señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para establecer una sesión UDP (Protocolo de Datagrama del Usuario) teniendo una trayectoria de calidad mejorada de servicio (QoS); La Figura 8B describe señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en el caso en donde los paquetes en una sesión UDP recibe los mejores esfuerzos de suministro en lugar de QoS mejorada; La Figura 8C ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para demoler una sesión UDP que se ha desconectado; La Figura 9A ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención durante el establecimiento de llamada del Protocolo de Iniciación de Sesión (SIP); La Figura 9B ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención durante la terminación de la llamada SIP; La Figura 9C ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para concluir una llamada SIP después de la detección de una desconexión por parte de la red; La Figura 9D ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para concluir una llamada SIP después de la detección de una desconexión mediante el dispositivo de acceso programable; La Figura 9E ¡lustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención durante la negociación de una llamada SIP; La Figura 10A ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para autorizar el registro de un grupo de multidifusión; La Figura 10B ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a un intento no autorizado para registrar un grupo de multidifusión; La Figura 10C ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a una búsqueda de mernbresía de grupo de multidifusión autorizado; La Figura 10D ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a una búsqueda de mernbresía de grupo de multidifusión no autorizado; La Figura 10E ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a la recepción de paquetes de multidifusión autorizados desde afuera de la red; La Figura 10F ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a la recepción de paquetes de multidifusión no autorizados desde fuera de la red; La Figura 10G ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención en respuesta a la recepción de paquetes de multidifusión autorizados desde la red; y La Figura 10H ilustra señalización ilustrativa en un sistema de acceso en red de acuerdo con la presente invención para manejar paquetes de multidifusión no autorizados recibidos desde la red.

DESCRIPCION DETALLADA DE UNA MODALIDAD PREFERIDA Arquitectura del Sistema de Acceso en Red Distribuido Con referencia otra vez a las figuras y en particular con referencia a la Figura 2, ahí se describe un diagrama de bloque de alto nivel de una porción de una red de comunicación 30 que tiene un sistema de acceso en red distribuida 31 de acuerdo con la presente invención. Como se ilustra, la red de comunicación 30 puede estar acoplada al equipo de un número de clientes (uno de los cuales está representado por un d ireccionador de cliente 32) a través de una línea de acceso 34. Como en la Figura 1, la línea de acceso 34 puede emplear cualquiera de un número de tecnologías de red de transporte, tal como Ethernet, SONET, ATM y relevo por etapas, y además puede incluir hardware de agregación no ilustrado. Como con las redes convencionales, la red de comunicación 30 incluye uno o más enlaces de comunicación de núcleo 38 (por ejemplo, líneas tronco), acoplados a uno o más d ireccionadores núcleo 36. Sin embargo, en contraste con redes de comunicación convencionales, tal como aquel ilustrado en la Figura 1, un direccionador de cliente 32 no se intercomunica con la red de comunicación 30 a través de un direccionador de borde propietario, monolítico. En su lugar, el equipo del cliente, tal como el direccionador del cliente 32, se intercomunica con la red de comunicación 30 a través del sistema de acceso en red 31 que distribuye las funciones de los direccionadores de borde tradicionales (así como funcionalidad adicional) entre tres módulos lógicos; un dispositivo de acceso programable (PAD) 40, un procesador externo 42, y una d ireccionador de acceso 44. De acuerdo con una modalidad preferida de la presente invención, el direccionamiento básico de paquetes entre puertos de entrada y salida de la red de acceso es realizado por el direccionador de acceso 44 mediante referencia a al cuadro de envíos 50 según determinado por los cuadros de direccionamiento del Protocolo de Compuerta Exterior (EGP) y el Protocolo de Compuerta Interior (IGP) 52, y 54. Sin embargo, las funciones de condicionamiento de envío y tráfico genérico tales como marcación, políticas, monitoreo, configuración, y filtración, son implementadas en PAD 40, y las funciones de servicio, tales como interpretación de mensajes, señalización, control de admisión e invocación de políticas, son implementadas en el procesador externo 42. Dada esta distribución de funcionalidad, los paquetes entrantes y salientes están típicamente comunicados entre enlaces de comunicación de núcleo 38 y direccionador del cliente 32 a través de PAD 40, direccionador de acceso 44, y direccionador de núcleo 36 (y opcionalmente una conmutación adicional de la red de acceso, tal como un conmutador ATM o MPLS 60). Sin embargo, si la funcionalidad de filtrado de PAD 40 detecta flujos de paquetes para los cuales ser requieren servicios adicionales, PAD 40 pasa mensajes apropiados al procesador externo 42 para procesamiento del servicio a través de una Interfase de Mensaje, Reporte y Control (MC I) 58, la cual puede ser accesada a través de una Interfase de Programación de Aplicación (API) en la PAD 40 y el procesador externo 42. La distribución de la funcionalidad entre el direccionador de acceso 44, PAD 40 y el procesador externo 42 en esta forma al proveedor del servicio (o aún a terceros) la libertad de extender y modificar servicios existentes, crear nuevos servicios o agregar más poder de procesamiento al procesador externo 42 sin afectar adversamente el funcionamiento de los envíos de la PAD 40 y el funcionamiento del direccionamiento o funcionalidad del direccionador de acceso 44. Para implementar una funcionalidad deseada para la PAD 40 y el procesador externo 42, el proveedor del servicio (o aún un cliente o un tercero) pueden definir reglas de políticas en la base de datos de políticas 46 de uno o más servidores de políticas 48 (también denominados como punto de decisión de política (PDP)). El servidor de políticas 48 entonces toma decisiones de políticas que controlan la funcionalidad y operación de la PAD 40 y procesador externo 42 mediante la referencia a las reglas de políticas almacenadas en la base datos de políticas 46. El servidor de políticas 48 comunica las decisiones de políticas y parámetros de configuración asociados al procesador externo 42 y/o PAD 40 al procesador externo 42 a través de la Interfase de Políticas de Servicio (SPI) 56, el cual puede ser accesado, por ejemplo, a través de una API o servidor de políticas 48 y procesador externo 42. La comunicación a través de SPI 56 puede emplear cualquiera de un número de protocolos de investigación de políticas, incluyendo el Servicio de Políticas Abiertas Comunes (COPS) y el Protocolo de Acceso de Directorio de Peso Ligero (LDAP), los cuales respectivamente están definidos a través de las RFCs 2748 y 2251 de Fuerza de Tareas de Ingeniería del Internet (IETF), las cuales se incorporan aquí por referencia. El procesador externo 42 transmite parámetros de configuración par PAD 40, si hay cualquiera, a PAD 40 a través de MCRI 58. Como se discute más adelante, el sistema de acceso en red 31 también permite al proveedor del servicio (o aún a un tercero) desplegar funcionalidad adicional en el procesador externo 42 desarrollando un controlador de servicio para soportar la funcionalidad e instalación del controlador del servicio en el procesador externo 42. También se puede implementar funcionalidad adicional en el sistema de acceso en red 31 utilizando NMS (Sistema de Administración de Red) 72, el cual también se denomina como un OSS (Sistema de Operación y Soporte). NMS 72 monitorea, controla, reporta alarmas a, y configura (por ejemplo, asigna una dirección IP a) cada uno de los componentes del sistema de acceso en red 31 a través de interfases 73-77. NMS 72 también preferiblemente incluye facturación y facilidades de contabilidad que asignan costos para los servicios a los clientes apropiados, por ejemplo, en respuesta a mensajes desde los controladores de servicios en el procesador externo 42. Como se ilustra adicionalmente en la Figura 2, un sistema de acceso en red 31 de la presente invención permite la flexibilidad en la colocación e implementación de conmutación de redes. Por ejemplo, una red ATM o MPLS (Conmutación de Etiqueta Multi-Protocolo) pueden ser utilizadas para acoplar una o más PADs 40 al puerto de un direccionador de acceso 44 a través de un interruptor ATM o MPLS 60, de esta forma permitiendo que los bloques de señalización y políticas funcionales 62 y 64 sean implementados separadamente a partir del direccionador de acceso 44. Si es así, sin embargo, la señalización se implementa a través del direccionador de acceso 44, el interruptor 60 puede ser eliminado. El interruptor 60 también puede alternativamente ser interpuesto entre el direccionador de acceso 44 y el direccionador de núcleo 36 un interruptor de agregación. Además, el direccionador de acceso 44 puede ser implementado por un procesador externo 42 operando el software de direccionamiento controlando una PAD 40 grande.

Dispositivo da Acceso Proqramable (PAD) Haciendo referencia ahora a la Figura 3, ahí se ilustra un diagrama de bloque de alto nivel de los elementos lógicos comprendiendo una modalidad ilustrativa de un PAD 40 de acuerdo con la presente invención. Como se observó anteriormente, el PAD 40 es un dispositivo de acceso programable conteniendo funciones de clasificación de envío y paquetes requeridos junto con otros módulos funcionales de acondicionamiento de tráfico que implementan cualquier combinación deseada de marcación, políticas, monitoreo, y configuración de paquetes entrantes y salientes. En una modalidad típica, PAD 40 se implementa como una combinación de software y hardware de direccionador convencional que coopera para proveer la funcionalidad de los módulos ilustrados. (En la Figura 3, la ilustración en líneas punteadas se utiliza para indicar los módulos funcionales opcionales). Hablando de manera general, los módulos funcionales de PAD 40 están configurados lógicamente en trayectorias de tráfico entrante (por ejemplo, desde el direccionador del cliente 32) o saliente (por ejemplo, al direccionador del cliente 32), con la trayectoria entrante incluyendo el filtro de encabezado del paquete 80, marcador/custodio 82, monitor(es) 84, cuadro de envío 86 y almacenamiento temporal de salida y programador 88. La similitud y trayectoria de salida incluye un filtro de encabezado de paquetes 90, cuadro de envíos 86, monitor(es) 92, marcador/configurador 94 y almacenamiento temporales de salida y programador 96. Las funciones de todos estos módulos funcionales pueden ser independientemente configuradas o programadas a través de un procesador externo 42 a través de MCRI 58. Los paquetes entrantes recibidos del direccionador del cliente 34 en la interfase externa de PAD 40 primero son procesados por el filtro de encabezado de paquete 80, el cual distingue entre varios tipos de mensajes utilizando cualquiera de uno o una combinación de tipos de protocolos, Dirección Fuente (SA), Dirección de Destino (DA), Tipo de Servicio (TOS), Punto de código de Servicios Diferenciados (DSCP), Puerto Fuente (SP), Puerto de Destino (DP), y otros campos de un paquete (por ejemplo, capa 4 y campos de capa más alta tal como SYN, ACK, RST, y banderas FIN TCP) sobre los cuales el filtro de encabezado de paquete 80 es configurado para filtrar. Importantemente, además de la filtración sobre la información de la capa 3, el filtro de encabezado de paquete 80 tiene la habilidad de identificar tipos de mensaje de capa de nivel más alto (es decir, capas 4-7) o campos específicos y enviar esos mensajes desde/a el procesador externo 42 con base en los parámetros de filtro configurados. De esta manera, con base en esta configuración del filtro y los campos de un paquete entrante, el filtro de encabezado de paquete 89 dirige el paquete ya sea un procesador externo 42 a través de la interfase de mensajes 100 o a un marcador/vigilante específico 82. Se debe notar que esa interfase de mensaje 100 también puede inyectar un paquete especificado por el procesador externo 42 en ya sea el filtro de encabezado de paquetes 80 y 90. En respuesta a la recepción de una corriente de paquetes desde el filtro de encabezado de paquetes 80, el marcador/vigilante 82 dirige la corriente de paquetes aplicando una o más señales o algoritmos de goteo de cubeta para determinar si la corriente del paquete se adapta a los parámetros de tráfico establecidos a través de la interfase de control 104. Como un resultado de la función de políticas, el marcador/vigilante 82 puede descartar paquetes no adaptados, paquetes no adaptados marcados (por ejemplo, con una prioridad más alta o más baja), y/o paquetes no adaptados contados, dependiendo de sus configuraciones. Si la marcación es requerida, el marcador/vigilante 82 puede fijar pequeños bits en los Servicios Diferenciados (Diff Serv)/byte TOS en el encabezado del paquete IP, y/o el campo experimental MPLS de 3 bits, y/o el campo de etiqueta MPLS de 20 bits, y/u otros campos según configurados a través de la interfase de control 104 para esa corriente de paquetes particular. Dentro de la trayectoria entrante, uno o más monitores 84 teniendo diferentes funciones pueden ser opcionalmente incluidos. Por ejemplo, estos monitores 84 pueden incluir un monitor de uso que rastrea estadísticas para diferentes tipos de tráfico de capa, capa 2, capa 3, capa 4 y capas más altas (por ejemplo, para monitorear un Convenio de Nivel de Servicio (SLA)). Los monitores 84 también pueden incluir un monitor de falla/problemas/depurar que verifique la conformación con estándares y asistir en la depuración del código y diagnosis de fallas guardando y reportando depósitos de memoria y otra información relacionada con el procesador externo 42 a través de la interfase de reportes 102 y MCRI 58. Para regular los mensajes de reporte, umbrales y otros criterios puede ser configurado para invocar un evento de reporte. Los mensajes de reporte enviados al procesador externo 42 a través de los monitores 84 pueden resumir la información de uso para un cliente particular, reportar la ocurrencia de un flujo de tráfico de prioridad alta, alertar al procesador externo 42 de un gran volumen de tráfico fuera de banda, reportar una inactividad de un flujo monitoreado, etc. Después del procesamiento a través del filtro de encabezado de paquete 80 (y opcionalmente a través de marcador/vigilante 82 y monitores 84), los paquetes entrantes son procesados por el cuadro de envíos 86. El cuadro de envíos 86 mantiene la entradas para cada trayectoria de envío, en donde cada trayectoria de envío está representada por los atributos de flujo de paquete, tales como DA, SA, TOS, PT, SP, DP, el puerto entrante, y el puerto de salida correspondiente al cual PAD 40 envía el paquete a través de la red de acceso hacia el direccionador de acceso 44. Utilizando estas entradas del cuadro de envíos, el cuadro de envíos 86 envía paquetes a los puertos de salida apropiados y pasa los paquetes a los almacenamientos temporales de salida y programador 88. Los almacenamientos temporales de salida y programador 88 registran los paquetes listos para transmisión sobre la red de comunicación 30 y programan la transmisión de dichos paquetes. El registro dentro de los almacenamientos temporales de salida 88 que pueden comprender un individual o preferiblemente múltiple almacenamiento temporal, preferiblemente está configurado para soportar múltiples clases de QoS, o aún QoS para cada flujo individual. Por ejemplo, un porcentaje o una cantidad fija de espacio de registro puede ser asignado a una investigación sirviendo una clase genérica de tráfico o para flujo de tráfico particular clasificado a través de DA, SA, TOS, PT, SP y/o DP. El programador de paquetes entonces aplica una petición firmada pesada y/o otros algoritmos a múltiples investigaciones multíplexando los diferentes flujos de tráfico. La combinación de almacenamiento temporal y mecanismos de programación pueden colocar un limite en el retraso de la cola para transmitir un paquete a través de PAD 40, de esta forma garantizando un valor definido para el parámetro de variaciones de QoS para los flujos de tráfico seleccionados. Los almacenamientos temporales y programador 88 también pueden aplicar CBQ (Hacer cola con base en la Clase), WFQ (Hacer Cola de Peso Justo), WRR (Petición Firmada Pesada), u otros algoritmos compartidos de enlace para optimizar la comunicación. La trayectoria de salida a través de PAD 40 es similar a la trayectoria de entrada, excepto por la inclusión del marcador/configurador 94 en lugar del marcador/vigilante 82. Como se apreciará por aquellos expertos en la técnica, el marcador/configurador 94 descarta los paquetes no adaptados, envía paquetes marcados a almacenamiento temporal de salida apropiado para las varias diferentes colas y programador 96 para controlar el retraso, variaciones y pérdida del flujo del paquete saliente, o simplemente cuenta los paquetes no adaptados. Un PAD 40 de acuerdo con la presente invención puede ser desplegado en un número de ubicaciones en una red para llevar a cabo la administración del tráfico y control de políticas. Por ejemplo, un PAD 40 puede ser colocado en una red de acceso del cliente (por ejemplo, fibra, xDSL, módem por cable, WAP (Protocolo de Acceso Inalámbrico), etc.) conectando el equipo del cliente a una red del proveedor controlado por procesadores externos localizados regionalmente 42. Alternativamente, un PAD 40 puede ser desplegado en un Punto de Presencia del proveedor del servicio (POP), interconectando un sitio del cliente sobre una línea privada, FR, ATM, MPLS o una red de acceso Ethernet. Un PAD 40 de acuerdo con la presente invención también puede estar localizado de frente a una granja de servidor que puede estar en el POP del proveedor o en un sitio del cliente. La forma en la que una red distribuida de PADs 40 envía paquetes al direccionador de acceso 44 está configurada en el cuadro de envíos 86 por el procesador externo 42 utilizando la inferíase de control 104.

Procesador Externo Con referencia ahora a la Figura 4, ahí se ¡lustra un diagrama de bloque de alto nivel describiendo los elementos lógicos comprendiendo una modalidad preferida de un procesador externo 42 de acuerdo con la presente invención. El procesado externo 42 puede ser implementado utilizando cualquiera o ambos del software y hardware, dicho hardware puede incluir hardware de computación de propósito general o hardware de propósito especial. Aunque las implementaciones solo de software del procesador externo 42 que se ejecutan en el hardware de un PAD 40 son posibles, el procesador externo 42 es preferiblemente implementado con un hardware independiente para permitir el procesamiento del servicio operado a través del procesador externo 42 sea fácilmente escalado a través de la instalación de hardware de procesador externo de funcionamiento más alto. La separación del procesador externo 42 permite la asignación dinámica de los recursos de procesamiento dentro del procesador externo 42 en respuesta a los patrones del tráfico de acceso sin degradar el funcionamiento de los envíos a PAD 40. Además, como se muestra en la Figura 4, la implementación del procesador externo 42 separadamente de PAD 40 permite que un procesador externo 42 de servicio a múltiples PADs 40a y 40b (las cuales pueden estar localizadas en distintas ubicaciones físicas) o, alternativamente, permite a múltiples procesadores externos 42 dar servicio a una PAD 40 individual. La asociación de un PAD 40 con múltiples procesadores externos 42 proporciona tolerancia de fallas mejorada. En una modalidad preferida, el procesador externo 42 principalmente realiza tres tipos de procesamiento: invocar servicios de políticas, señalizar configurar y tirar conexiones de red de acceso, y configurar uno o más PADs asociados 40. Para coordinar estas diferentes funciones de procesamiento, el procesador externo 42 contiene uno o más controladores de servicio 120, cada uno de los cuales preferiblemente controla estas tres funciones para un tipo de servicio respectivo. Por ejemplo, los controladores de servicio 120 pueden incluir cualquiera o todos de un Controlador de Servicio de Llamada de Conferencia (CCSC), un Controlador de Servicio de Comercio Electrónico (ECSC), un Controlador de Servicio de Telefonía IP (IPTELSC), un Controlador de Servicio de Ancho de Banda Reservado (RBSC), y un Controlador de Servicio de Multidífusión (MSC). Dicho control específico de servicio puede ser implementado ya sea con controladores de servicio dedicado o con controladores genéricos que cada una soporta APIs especificas de servicio. Cada controlador de servicio preferiblemente mantiene un cuadro de sesión registrando todas sus sesiones activas con un PAD 40. Como se muestra además en la Figura 4, el procesador externo 42 incluye, para cada PAD asociada 40, un controlador de PAD respectivo 124. Bajo la dirección del controlador(es) de servicio 120, cada controlador de PAD 124 configura el cuadro de envíos 86, los filtros de encabezado de paquete 80 y 90, marcador/vigilante 82, marcador/configurador 94, monitores 84 y 92 y el almacenamiento temporal de salida y programadores 88 y 96 de la PAD 40 asociada invocando comandos o escritos entendidos por la interfase de control 104. El procesador externo 42 también contiene un procesador de mensajes respectivo 122 para cada PAD 40 asociado. Los procesadores de mensajes 122, cada uno comunica los mensajes a y de la interfase de mensajes 100 del PAD 40 asociado. Una vez la recepción de un mensaje desde un PAD 40, el cual es usualmente un mensaje recibido desde el direccionador del cliente 32, un procesador de mensajes 122 analiza el mensaje e informa al controlador de servicio apropiado (según determinado por el tipo de servicio) de sus contenidos. Como se indica en la Figura 4, el cualquier momento dado no todos los PADs 40 pueden ser configurados para manejar todos los tipos de servicios; asi, un controlador de servicio particular 120 puede comunicar mensajes con menos de todos los PADs 140. Como se indica por la ilustración en líneas punteadas, el procesador externo 4 puede además incluir un procesador de reportes 126 para cada PAD (por ejemplo, PAD 40a) conteniendo monitores opcionales 84 y 92 e interfase de reportes 102. El procesador de reportes 126 recibe mensajes de reporte desde la interfase de reporte PAD correspondiente 102 y transmite mensajes de reporte apropiados a uno o más controladores de servicio 120. El procesador de reporte 126 también puede configurar la interfase de reportes 102 de un PAD 40 para especificar el tipo(s) aceptable de mensajes de reporte, contenido de los mensajes de reporte, reporte de eventos, etc. Una vez la recepción de un mensaje de reporte desde el procesador de reportes 126 u otro tipo de mensaje desde un procesador de mensajes 122, un controlador de servicio 120 traduce el mensaje en una o más investigaciones de política y transmite la investigación o investigaciones de política al servidor de política 48 a través de SPI 56. Por ejemplo, si SPI 56 emplea COPS, el controlador de servicio 120 traducirá los mensajes RSVP y SIP a mensajes COPS (RSVP) y COPS (SIP), respectivamente. Un controlador de servicio 120 también puede pasar un mensaje a otro controlador de servicio 120 para obtener servicios adicionales a través de la interfase 121. En respuesta a la recepción de una decisión de política desde un servidor de políticas 48, el controlador de servicio 120 puede inyectar uno o más paquetes en el flujo del tráfico a través del procesador de mensajes 122, configura un PAD 40 a través del controlador de PAD 124 o controlar la señalización dentro o fuera de la red de comunicación 30 a través de los controladores de señalización 128a y 128b. Los controladores de señalización 128 soportan los protocolos de señalización (por ejemplo, RSVP, Protocolo de distribución de Etiqueta (LDP), Interfase de Red de Red Privada (PNNI), transmisión de cuadro o Interfase de Red de Usuario ATM (UNI), etc. para configurar o tirar una Conexión Virtual (VC) o Trayectoria Conmutada de Etiqueta (LSP) a través de la red. Una configuración VC o LSP a través de un controlador de señalización 128 puede tener un QoS especificado. Para reducir el número de mensajes pasados entre los controladores de servicio 120 y un servidor de políticas 48 a través de SPI 56, los controladores de servicio 120 cada uno preferiblemente ocultan las reglas de políticas frecuentemente utilizadas en una memoria de política respectiva 130, Por consiguiente, si la información de política para una investigación de políticas de un mensaje entrante ya está memorizada, un controlador de servicio 120 puede prescindir de enviar una investigación al servidor de políticas 48 y hacer una decisión de política a través de las reglas de políticas de referencia en su memoria de políticas 130. Además, cuando un controlador de servicio 120 investiga el servidor de políticas 48 con una nueva solicitud de servicio, el controlador de servicio 120 puede solicitar al servidor de políticas 48 descartar toda la información de política relacionada desde la base de datos de políticas a su memoria de políticas 130. Sin embargo, existe un trueque entre el número de investigaciones de política y la frecuencia de memoria refrescada y la cantidad de información de política descargada desde el servidor de políticas 40 en cada refrescada. El objetivo es memorizar políticas para los servicios IP que requieren investigaciones de políticas intensivas, tales como llamadas SIP, mientras evitan la búsqueda de políticas memorizadas de otras sesiones (por ejemplo, sesiones TCP) que generalmente generan solamente una investigación de políticas en toda su vida.

Interfases del Sistema de Acceso en Red Como se describió anteriormente, el sistema de acceso en red de la presente invención soporta por lo menos dos interfases: SPI 56 y MCRI 58. Cada una de estas interfases es examinada en turno más adelante. Como se resume en el Cuadro 1 a continuación, SPI 56 preferiblemente soporta por lo menos un tipo de mensaje que es enviado desde los controladores de servicio 120 al procesador externo 42 al servidor de políticas 48, particularmente, investigaciones con respecto a requerimientos de políticas. Dichas investigaciones de políticas incluyen una bandera que pueden ser fijada para solicitar que el servidor de políticas 48 descarte las reglas de políticas de la investigación en la memoria de política 130 del controlador de servicio solicitante 120.

SPI 56 también preferiblemente soporta por lo menos cinco tipos de mensajes que son enviados desde el servidor de políticas 48 a los controladores de servicio 120. Los tipos de mensajes enviados a través de SPI 56 desde el servidor de políticas 48 a los controladores de servicio 120, que también están resumidos en el Cuadro I, incluyen aprobación de transacción y mensajes rechazados, mensajes especificando parámetros de configuración e información de política conteniendo mensajes que van ser memorizados en las memorias de políticas 130. Además, el servidor de política 48 puede enviar mensajes al procesador externo 42 que indica las configuraciones para los parámetros del nivel de sesión en la PAD 40. Como entiende por aquellos expertos en la técnica, un parámetro de nivel de sesión importante es un cronómetro de inactividad que cuenta el tiempo que ha transcurrido desde que un paquete ha sido recibido en una sesión, y más que una cantidad especificada de tiempo ha transcurrido, señal de que la sesión debería ser cerrada por retraso de la actividad.

CUADRO I La comunicación entre el servidor de políticas 48 y el procesador externo 42 sobre SPI 56 pueden se ya sea solicitada o no solicitada. En la operación del modo de no solicitado el servidor de políticas 48 envía los parámetros de configuración para el procesador externo 42 y PAD 40 al procesador externo 42 en ausencia de la solicitud de políticas. Alternativamente, en el modo de comunicación solicitada, el servidor de políticas 48 envía decisiones de política y parámetros de configuración para el procesador externo 42 en respuesta a una solicitud de políticas. Como se muestra en la Figura 2, las solicitudes de políticas pueden ya sea ser enviadas al procesador externo 42 o, debido SPI 56 preferiblemente emplea un protocolo de investigación de políticas, por un tercero (por ejemplo, un servidor de políticas del cliente). En cada caso, el servidor de políticas 48 recibe una solicitud de política a través de SPI 56. La solicitud de políticas típicamente especifica un servicio solicitado y requiere una respuesta indicando en donde va a ser provisto el servicio solicitado dando los parámetros del servicio (por ejemplo, identidad del solicitante, tipo y cantidad de servicio solicitado, etc.) y si es asi, las configuraciones apropiadas para el servicio. En respuesta a la recepción de una solicitud de políticas, el servidor de políticas 48 interroga a la base de datos de políticas 46 para accesar las reglas de política apropiadas dando los parámetros proporcionados en la solicitud de políticas. El servidor de políticas 48 entonces toma decisiones de políticas para la solicitud de políticas utilizando las reglas de políticas accesadas e información de uso. Por ejemplo, el servidor de políticas 48 puede rastrear la cantidad de ancho de banda reservado por un cliente particular (o regla de política) y aprobar o rechazar una nueva solicitud de servicio comparando la cantidad de ancho de banda reservada remanente que está sin utilizar (información de uso) y el cantidad de ancho de banda requerida para proporcionar el servicio solicitado. El servidor de políticas 48 entonces suministra las decisiones de política resultantes, las cuales pueden ser "aprobado", "rechazado", y/o configuración de los parámetros desnivel de la sesión para el procesador externo 42 y PAD 40, al procesador externo 42 a través de SPI 56. Cambiando ahora a la interfase MCRI 58, el Cuadro II a continuación, resume tipos de mensajes que son enviados a través de PAD 40 al procesador externo 42. Como se indicó, estos tipos de mensajes pueden ser convenientemente categorizados a través de referencia de en cual de la interfase de mensajes 100, interfase de reportes 102, e ¡nterfase de control 104 está la fuente de los mensajes. Como se notó anteriormente, la interfase de mensajes 100 de PAD 40 pasa los mensajes capturados a través de filtros de encabezado de paquetes 80 y 90 al procesador de mensajes 122 del procesador externo 42. Los mensajes que son pasados al procesador de mensajes 122 pueden ser filtrados del flujo de paquetes entrantes o salientes con base en SA, DA, PT, SP, DP y/o otros campos de paquete tales como banderas TCP (por ejemplo, SYN, ACK, RST, FIN, etc.) así como tipos de mensaje de capas 4-7 y campos. La interfase de control 104 envía mensajes de respuesta de control al controlador de PAD 124 en respuesta a la recepción de un mensaje de comando de control. Si el comando se completa exitosamente, (por ejemplo, una configuración de un monitor 84 se ha actualizado exitosamente), la ¡nterfase de control 104 regresa un comando de confirmación al controlador PAD 124. Sin embargo, si un comando no puede ser completado debido a la sintaxis inapropiada, no disponibilidad de los recursos requeridos, etc., entonces la interfase de control 104 notifica al controlador PAD 124 de la falla del comando con una indicación de falla de comando. La interfase de reporte 102 de PAD 40 envía mensajes de reporte para reportar al procesador 126 del procesador externo 42. Los mensajes de reporte tabulados en el Cuadro II incluyen mensajes proporcionando información acerca de sesiones monitoreadas, mensajes relacionados a la comunicación entre PAD 40 y los controladores de servicio 120 del procesador externo 42, y mensajes conteniendo estadísticas recolectadas a través de los monitores 84 y 92. Para ciertos protocolos, tales como TCP y SIP, PAD 40 implementa una máquina de estación para cada sesión activa. Si una máquina de estación TCP detecta que una sesión TCP activa particular ha tenido un número de retransmisiones en exceso de un umbral de retransmisión establecido, la interfase de reportes 102 envía un mensaje notificando al procesador de mensajes 122 del procesador externo 42 que el umbral de retransmisión TCP ha sido excedido, de esta manera indicando que la sesión TCP ha fallado. El procesador de reportes 126 similarmente reporta otras fallas de sesiones tales como al expiración de un cronómetro de inactividad en ciertas sesiones de protocolo IP, tal como TCP y SIP. Para otros flujos de datos (por ejemplo, sesiones UDP) que no tienen máquinas estación asociadas para asegura la confiabilidad, la interfase de reportes 102 de PAD 40 envía mensajes de reporte "Actividad Detectada" cuando la actividad es detectada en la sesión. En la modalidad preferida de la presente invención representada por el Cuadro II, el estado de la conexión entre un PAD 40 y el procesador externo 42 es indicado a través de mensajes mantenidos en vivo que son periódicamente intercambiados entre PAD 40 y el procesador externo 42 asociado. La ausencia de un mensaje de mantener en vivo de la PAD 40 indica la falla en la conexión entre PAD 40 y el procesador externo 42 y/o la falla de PAD 40 por sí mismo. Dichos mensajes de mantener en vivo son preferiblemente transmitidos entre la inferíase de reporte 102 y el procesador de reportes 126; sin embargo, sino se implementa ninguna interfase de reporte, la mensajería de mantener en vivo puede alternativamente ser provista por la interfase de mensajes 100. Los controladores de servicio 120 dentro del procesador externo 42 también son sometidos a fallas o reasignaciones dinámicas a diferentes servicios (por ejemplo, por razones de equilibrio de cargas). En el caso de una falla en el procesador externo 42 soportando múltiples controladores de servicio 120 o una redistribución de la responsabilidad del servicio entre los controladores de servicio 120, el nuevo controlador del servicio 120 al cual se transfiere la responsabilidad para la sesión debe recibir información del estado perteneciente a todos las sesiones activas del antiguo controlador de servicio 120. Por consiguiente, en el caso de una así llamado con conmutación que asigna un PAD 40 a un procesador externo 42 preferido, PAD 40 preferiblemente reporta la información de estado para las sesiones activas al procesador de reportes 126 del procesador externo 120 en el mensaje de sincronización de estado. Haciendo a PAD 40 responsable de proporcionar la información de estado de sesión al nuevo controlador de servicio 40 responsables de proveer la información de estado de la sesión al nuevo controlador de servicio 120 en esta manera ventajosamente desahoga a los controladores de servicio 120a y 120b de la responsabilidad de sincronizar los estados de las sesiones, lo cual es un proceso intensivo de mensajes que degrada el funcionamiento del controlador de servicio durante operación normal. Este aspecto del diseño logra la tolerancia de fallas del hardware, software y fallas de red. El Cuadro II finalmente lista dos mensajes de reporte activados a través del monitoreo desarrollado por monitores opcionales 84 y 92. Primero, la interfase de reportes 102 puede proporcionar estadísticas de uso general sobre bases por cliente. Los controladores de servicio 120 en el procesador externo 42 pueden utilizar esta información estadística para medir la conformación de los SLAs y detectar ciertos eventos de interés. Segundo, la interfase de reporte 102 puede específicamente indicar en un mensaje de reporte que un umbral de tráfico predefinido por el cliente ha sido excedido. Un controlador de servicio 120 en el procesador externo 42 puede utilizar esta información para asignar recursos adicionales al tráfico del cliente (por ejemplo, para asegura la conformación a un SLA) o puede notificar al servidor de facturación 72 que se debe hacer un ajuste en la facturación del cliente (por ejemplo, si la facturación se basa en el uso). Por supuesto, mensajes de reporte adicionales también pueden ser definidos.

CUADRO 2 Haciendo referencia ahora al Cuadro III, se resumen los tipos de mensajes enviados a PAD 40 desde el procesador 122, controlador de PAD 124, y procesador de reportes 126 del procesador externo 42 a través de MCRI 58. En la modalidad de interfase mostrada en el Cuadro III, el procesador de mensajes 122 puede enviar por los menos dos tipos de mensajes a la interfase de mensajes 100. Primero, el procesador de mensajes 122 puede enviar a la interfase de mensajes 100 uno o más paquetes para ser inyectados en ya sea, el flujo de paquetes entrantes o salientes. Segundo, el procesador de mensajes 122 puede enviar a la interfase de mensajes 100 un mensaje indicando banderas de campo de paquete en la interfase de mensajes 100 para ser fijados o deshabilitados para que la interfase de mensajes 100 los pase o prevenga a la interfase de mensajes 100 de pasar mensajes particulares al procesador de mensajes 122 con base en los contenidos de varios campos del paquete, tales como SA, DA, PT, SP, DP, etc. Como se estableció en el Cuadro III, los mensajes de control del controlador de PAD 124 para la ínterfase de control 104 a través de MCRI 58 incluyen un número de mensajes de configuración que permiten al controlador de PAD 124 configurar cualquiera de los módulos funcionales de filtrado, marcación, políticas, monitoreo, almacenamiento temporal, programación, configuración y envío 80-96 de PAD 40 a través de la Ínterfase de control 104. En particular las memorias de salida y programadores 88 y 96 pueden ser configurados para asignar un número de almacenamientos temporales o tamaños de almacenamientos temporales por clase de tráfico o flujo de tráfico o para implementar CBQ, WFQ, WRR y otros algoritmos de programación de almacenamiento temporal. El controlador de PAD 124 también puede marcar/configurar 94 para emplear algoritmos de configuración estáticos o adaptativos y puede configurar el marcador/configurador 94 para implementar la configuración por flujo de tráfico o por bases de clase de tráfico. El controlador PAD 124 además puede configurar el cuadro de envíos 86 en respuesta a una solicitud a través de un controlador de servicio 120 con el fin de habilitar al controlador del servicio 120 para asociar un flujo de datos con un ATM SVC o un MPLS LSP. Además de los mensajes de control general utilizados para configurar módulos funcionales 80-96, MCRI 58 también soporta varios mensajes de control utilizados para configurar aspectos particulares de los módulos funcionales de PAD 40. Por ejemplo, filtros de encabezado de paquete 80 y 90 pueden ser configurados para bajar paquetes de mu Itid ¡fusión de una fuente no autorizadas, para admitir o negar direccionamiento de fuente para el flujo de datos, o para admitir solamente paquetes con direcciones de fuentes específicas. Además, el controlador de PAD 124 puede actualizar el cuadro de envíos 86 con trayectorias de configuración SVC y LSP a través de un controlador de servicio 120 utilizando un controlador de señalización 128. La interfase de reportes 102 puede ser configurada a través de un mensaje de control "Fijar banderas de reporte" para habilitar o deshabilitar el reporte de eventos seleccionados, configurando o volviendo a configurar banderas de reporte correspondientes a esos eventos. PAD 40 también puede estar configurada a través de mensajes de control MCRI para fijar el umbral de notificación de retransmisión TCP, cronómetros de inactividad, cronómetros de actividad, y umbral de tráfico discutidos anteriormente. Finalmente, los recursos de procesamiento de PAD 40 y almacenamiento de memoria temporal de salida y programador 88, 96 pueden ser configurados a través de un mensaje de control "Asignar Recurso" enviado a través de MCRI 58 y la interfase de control 104 para asignar dinámicamente los recursos, tales como ancho de banda, colas de espera, y porciones del tiempo de procesamiento, a una interfase de cliente, un flujo de paquete, una clase, o un grupo de multidifusión.

Los mensajes de reporte enviado desde el procesador de reporte 126 al procesador externo 42 a PAD 40 están generalmente limitados para intercambiar mensajes de mantener en vivo con la interfase de reporte 102. El intercambio continuo de mensajes mantenidos en vivo informa a PAD 40 que el controlador de servicio asociado 120 es operativo. Si PAD 40 falla al recibir mensajes de mantener en vivo de un controlador de servicio 120, PAD 40 inicia una conmutación de servicio a un controlador de servicio secundario 120, como discute más adelante.

CUADRO 3 Tolerancia de Fallas Para prevenir una interrupción en el servicio en el caso de una falla del controlador del servicio, cada servicios está preferiblemente soportado por ambos, un controlador de servicio primario que ordinariamente proporciona el servicio y un controlador de servicio secundario que puede proporcionar el servicio si el controlador de servicio primario falla o si la conexión entre un PAD y el controlador de servicio primario se pierde. En una modalidad preferida de la presente invención, los controladores de servicio primario y secundario residen en procesadores externos 42 diversamente conectados a través de la red de acceso. En respuesta a la detección de una falla de comunicación con el controlador de servicio primario, PAD 40 realiza una conmutación al controlador de servicio secundario. Haciendo referencia ahora a la Figura 5A, ah( se describe un diagrama de tiempo-espacio mostrando la señal del sistema de acceso en red ilustrativo para conmutar la provisión del servicio de un controlador de servicio primario a un controlador de servicio secundario de acuerdo con la presente invención. En la Figura 5A, se asumió para propósitos de ilustración que el controlador del servicio 120a es el controlador de servicio primario y el controlador de servicio 120b es el controlador de servicio secundario. Durante la operación normal, un PAD 40 emplea un protocolo de comunicación confiable (por ejemplo, TCP) para intercambiar información con los controladores de servicio 120a y 120b del procesador externo asociado 42. Como se observó anteriormente, un mensaje de mantener en vivo es periódicamente intercambiado entre el procesador externo 42 y PAD 40 para mantener la sesión TCP activa. Cuando PAD 40 detecta una interrupción del mensaje de mantener en vivo, significando que la conexión al procesador de servicio primario 120a ha fallado, PAD 40 intenta configura una sesión TCP con el controlador de servicio secundario 120b, como se muestra en la Figura 5A a través de PAD 40 enviando un segmento de sincronización (SYN) al controlador de servicio secundario 120b. Si PAD 40 no tiene éxito al conectarse con el controlador de servicio secundario 120b (por ejemplo, no se recibió SYN ACK desde el controlador de servicio secundario 120), PAD 40 detiene el intento de aceptar nuevas sesiones y mantiene es estado y servicio para todas las sesiones activas actualmente hasta que la comunicación con el controlador de servicio primario 120a es restaurada. Si, sin embargo, PAD 40 exitosamente establece una sesión TCP con el controlador de servicio secundario 120b (por ejemplo, según se indica a través de la recepción de SYN ACK y la devolución de ACK), PAD 40, la cual mantiene una máquina de estación para cada sesión activa, sube la información del estado para todas sus sesiones activas controladas por el controlador de servicio primario que falló 120a al controlador de servicio secundario 120b. Ya que se recibe la información del estado a través del controlador de servicio secundario 120b es reconocida por el mensaje ACK, PAD 40 inicia el intercambio de los mensajes de mantener en vivo con el controlador de servicio secundario 120b. De esta forma, el servicio no es interrumpido por la falla de un controlador de servicio individual 120, y no se requiere de sincronización entre los co ntrol adores de servicio 120a y 120b. La comunicación entre PAD 40 y el controlador de servicio secundario 120b puede continuar y no revertirse al controlador de servicio primario 120a si no se desea una conducta de reversión. Sin embargo, por ahora se prefiere para la comunicación revertir al controlador de servicio primario 120a, si es posible, para mantener el equilibrio de cargas del procesamiento del controlador de servicio a través de los PADs distribuidos. Haciendo referencia ahora a la Figura 5B, ahí se describe un diagrama de tiempo-espacio mostrando señalización ilustrativa entre un dispositivo de acceso programable y un procesador externo durante una conmutación desde un controlador de servicio secundario a un controlador de servicio primario después de la restauración del controlador de servicio primario. El proceso de reversión empieza con el controlador de servicio primario 102a enviando un segmento SYN a PAD 40 para reestablecer una sesión TCP. PAD 40 en respuesta a la recepción de SYN con SYN ACK, del cual el controlador de servicio primario 120a confirma con un ACK. Una vez que una sesión TCP ha sido iniciada, PAD 40 sube los estados de las sesiones activas al controlador de servicio primario 120a, y el controlador de servicio 120a confirma la recepción de los estados de sesión con un ACK. Después de que los estados de sesión han sido exitosamente restaurados al controlador de servicio primario 120a, PAD 40 notifica al controlador de servicio secundario 120b que el controlador de servicio primario 120a ha sido restaurado a través del mensaje "Preparar para apagar". PAD 40 entonces cierra la sesión TCP con el controlador de servicio secundario 120b a través de un par de FIN (es decir, terminado) y apretón de manos ACK, la primera mitad de la cual es originada a través de PAD 40 y al segunda mitad de la cual es originada por el controlador de servicio secundario 120b. Después de que la conexión TCP es cerrada, el controlador de servicio secundario 120b elimina toda la información de estado relacionada con la sesiones transferidas al controlador de servicio primario 120a. PAD 40 de aquí en adelante resume los intercambios de mantener en vivo con el controlador de servicio 120a.

Implementaclón Metropolitana Con referencia ahora a la Figura 1B, ahí se describe una implementación metropolitana de una red de Proveedor de Servicio de Internet (ISP) incluyendo un sistema de acceso en red distribuido de acuerdo con la presente invención. La Figura 1B ilustra interconexiones físicas de componentes, en lugar de conexiones lógicas (por ejemplo, red), como se muestra en la Figura 2. Empezando desde el lado izquierdo, las LANs del cliente 14 se interconectan tanto a una red de acceso de nivel más bajo (por ejemplo, TDM, ATM o Ethernet) entre las redes de acceso metropolitanas 16' o directamente a un PAD 40. Como se muestra, PADs 40 también pueden estar localizadas en niveles más altos en la jerarquía de la red de agregación. Las consideraciones de ingeniería económica y/o funcionamiento determinan la colocación de los PADs 40. Por ejemplo, la agregación de una cantidad mínima de tráfico o la necesidad de accesar un enlace de acceso de baja velocidad puede conducir a la colocación de PAD 40 a niveles de red de acceso más altos o más bajos, respectivamente. Como se discutió anteriormente, PADs 40 realizan la ejecución de políticas, de esta manera alivian a los direccionadores de agregación (es decir, direccionadores de acceso 44) de algo de carga de trabajo. La determinación de las políticas también es removida de los direccionadores de agregación y es su lugar se colocan en procesadores externos redundantes 42 y PDPs 46. Para la mayoría de las implementaciones, los procesadores externos 42 podrían típicamente ser desplegados en una forma distribuida para cada área metropolitana, mientras que PDPs 46 podrían ser desplegados más escasamente sobre bases regionales. Como un resultado de aliviar algo de la carga de trabajo de los direccionadores de agregación, los direccionadores de acceso 44 pueden ser escalados para manejar capacidades de tráfico más grandes debido a que estos están optimizados para manejar la tarea más simple, aún esencial del direccionamiento del Internet. Las capacidades de la red ISP también son expandidas debido a que PADs 40, los procesadores externos 42 y PDPs 46 implementan no solamente la funcionalidad de los direccionadores de borde de estado de la técnica, sino también un número de funciones que no están actualmente disponibles en diseños de direccionadores monolíticos. Con el fin de ilustrar aspectos adicionales de la presente invención, ejemplos señalización de sistema de acceso en red y mensajería de varios escenarios operativos se describen a continuación con referencia a dibujos de espacio-tiempo genéricos. Los ejemplos ilustran implementaciones ilustrativas de señalización de nivel de red, conexión orientada y protocolos de transporte sin conexión, comunicación a nivel de aplicación, y administración de servicios de multidifusión con base en políticas.

Ejemplo de Señalización a Nivel de Red Con referencia ahora a la Figura 6, ahí se ilustra un diagrama de tiempo-espacio describiendo señalización a nivel de red ilustrativa utilizada para obtener una reservación de servicio a través del uso del Protocolo de Reservación de Recursos (RSVP). En el ejemplo ilustrado, una aplicación de cliente inicia el proceso de reservación mediante el envío de un mensaje RSVP PATH a PAD 40. Por ejemplo, la aplicación del cliente puede solicitar una trayectoria de ancho de banda especificado a un tiempo particular. Como se muestra en la Figura 6, el filtro de encabezado de paquete 80 de PAD 40 captura el mensaje RSVP PATH con base en el tipo de protocolo RSVP (es decir PT = 46) y lo envía al controlador de servicio apropiado 120 (el cual en este ejemplo es denominado como un Controlador de Servicio de Ancho de Banda Reservado (RBSC) 120 dentro de procesador externo 40.

En respuesta a la recepción del mensaje de trayectoria, RBSC 120 transmite una búsqueda de política apropiada al servidor de políticas 48 a través de SPI 56 (el cual en este caso se asume que implementa COPS) para determinar si el servicio de reservación está autorizado para este cliente. Si el servidor de políticas 48 regresa una decisión de política a RBSC 120 aprobando el servicio de reservación para este cliente, RBSC 120 regresa un mensaje RSVP PATH a PAD 40, el cual envía el mensaje PATH corriente abajo al punto de egreso de la red. Si el receptor en el último extremo de la red también aprueba la reservación, el receptor responde transmitiendo un mensaje de reservación (RESV) a PAD 40, el cual pasa el mensaje RESV a RBSC 120. En respuesta al mensaje RESV, RBSC 120 invoca otra búsqueda de política en el servidor de políticas 48 para cerciorarse de si los requerimientos de ancho de banda especificados por el mensaje RESV están autorizados para este cliente. En respuesta a esta segunda búsqueda, el servidor de políticas 48, el cual rastrea la asignación de ancho de banda para cada cliente, determina si el ancho de banda actualmente asignado más el ancho de banda solicitado es menor que el máximo autorizado de ancho de banda para este cliente. Si es así, el servidor de políticas 48 notifica a RBSC 120 una decisión de política indicando la aprobación. RBSC 120 entonces inicia señalización ATM o MPLS apropiada para configura un RVC o LSP utilizando un controlador de señalización más 128. Después de que RBSC 120 recibe la confirmación de la trayectoria solicitada de la red, RBSC 120 configura el filtro de encabezado de paquete 80 y el cuadro de envios 86 de PAD 40 para transmitir paquetes en el flujo de cliente sobre la SVC o LSP establecida. Además, RBSC 120 regresa el mensaje RESV a PAD 40 utilizando la interfase de mensaje 100, la cual envía el mensaje RESV corriente arriba a la aplicación del cliente. RBSC 120 también envía un mensaje de CONFIRMACION corriente abajo al receptor a través de PAD 40 para completar el apretón de manos utilizado para configurar la SVC o LSP.

Ejemplos de Transporte Orientados en Conexión Con referencia ahora a la Figura 7A-7G, se describen, una máquina de estado TCP y diagramas de tiempo-espacio de varios eventos TCP que juntos ilustran el manejo de protocolos de transporte orientado en conexión a través del sistema de acceso en red de acuerdo con la presente invención. Haciendo referencia primero a la Figura 7A, se describe una modalidad preferida de una máquina de estado mantenida para una sesión YCP en un PAD 40. Como se muestra, la máquina de estado TCP 140 incluye dos estados: un estado pasivo 142 en donde no hay una sesión TCP activa y un estado activo 144 en donde si hay una sesión TCP activa. La operación de la máquina de estado 140 mantiene el estado de sesión TCP durnte cuatro procesos TCP, incluyendo (1) abrir una sesión TCP en respuesta a un segmento de sincronización (SYN), (2) cerrar una sesión TCP en respuesta a un mensaje de terminado (FIN), (3) cerrar una sesión TCP que se ha interrumpido y (3) cerrar una sesión TCP en respuesta a un mensaje de reanudar (RST). En la Figura 7A, los mensajes asociados con cada una de estas operaciones se identifican mediante leyendas correspondientes (por ejemplo, "1.x" para abrir una sesión TCP, "2.x" para cerrar una sesión TCP en respuesta a un mensaje de FIN, etc.), y hay tiempo ordenado adicional a través de designaciones alfabéticas (por ejemplo, "1.a" precede "1.b", etc.). Como se ilustra, la apertura de una sesión TCP se inicia cuando la máquina de estado 140 está en estado pasivo 142 y PAD 40 recibe un segmento SYN. Como se ilustra con el número de referencia 150, filtro de encabezado de paquete 80 captura el mensaje SYN inicial recibido del cliente y lo pasa al controlador de servicio 120 dentro del procesador externo 42 que está designado para manejar los servicios TCP. En respuesta a la recepción del mensaje SYN, el controlador de servicio 120 busca en el servidor de políticas 48 con respecto a la sesión TCP para este cliente. Si el controlador de servicio 120 recibe una decisión de política indicando la aprobación de la sesión TCP, el controlador de servicio 120 regresa el segmento SYN a PAD 40 según indicado con el número de referencia 152. En respuesta a la recepción del mensaje SYN del controlador de servicio 120, la máquina de estado 140 cambia el estado de estado pasivo 142 a estado activo 144. PAD 40 envía el segmento SYN al receptor especificado por la dirección de destino y recibe un segmento SYN, ACK, del receptor, como se muestra con el número de referencia 154. La persona que envía completa el apretón de manos de tres direcciones para abrir la sesión TCP, contestando con un mensaje ACK, según descrito con el número de referencia 156. PAD 40 pasa el mensaje ACK representando el éxito del apretón de manos del controlador de servicio 120, como se muestra con el número de referencia 158. La recepción del mensaje ACK notifica al controlador de servicio 120 que la sesión TCP está abierta y origina que el controlador de servicio 120 agregue la sesión TCP a su cuadro de sesión activa. El controlador de servicio 120 entonces configura un cronómetro de inactividad y otros parámetros de esta sesión TCP en PAD 40 y regresa el mensaje ACK a PAD 40, como también se indica con el número de referencia 158. Después, los datos pueden ser transmitidos entre el cliente y el receptor a través de la sesión TCP activa, como se muestra con el número de referencia 159. Para cerrar una sesión TCP activa, ya sea el cliente o el receptor pueden enviar a PAD 40 un mensaje FIN. En respuesta a la recepción del mensaje FIN, PAD 40 reanuda la máquina de estado TCP 140 a estado pasivo 142 como se muestra con el número de referencia 160. PAD 40 entonces pasa el mensaje FIN al controlador de servicio 120 como se muestra con el número de referencia 162. El mensaje FIN notifica al controlador de servicio 120 que la conexión TCP está inactiva y origina que el controlador de servicio 120 elimine la sesión TCP de su cuadro de sesión activa. Como se ilustra, PAD 40 envía el mensaje FIN a su destino (es decir, ya sea al cliente o al receptor), el cual responde con un mensaje ACK y un mensaje FIN 164. La fuente entonces responde el último mensaje FIN con un mensaje ACK 166. En respuesta a la recepción del último mensaje ACK, PAD 40 elimina la máquina de estado 140 para la sesión TCP. Como además se ilustra en la Figura 7A, PAD 40 también cerrará una sesión de TCP activa si el tiempo de inactividad para la sesión de TCP expira. En respuesta a la expiración del tiempo de inactividad para una sesión de TCP activa, PAD 40 hace una transición en la máquina de estado 140 del estado activo 144 al estado inactivo 142, como se ilustra con el número de referencia 170. PAD 40 también reporta un error de intervalo al controlador de servicio 120, como se muestra en el número de referencia 172. En respuesta a la recepción del mensaje de error de intervalo, el controlador de servicio 120 elimina la sesión de TCP de su tabla de sesión activa y actualiza la configuración de PAD 40 para remover el tiempo de inactividad y otra información de configuración asociada con la sesión de TCP. PAD 40 entonces elimina a la máquina de estado 140 para la sesión de TCP. PAD 40 también cierra una sesión TCP en respuesta a la recepción de un mensaje de restablecimiento (RST) desde un tercero a una conexión TCP. En respuesta a la recepción del mensaje RST, PAD 40 hace transitar la máquina de estado 140 de un estado activo 144 a un estado inactivo 142, como se muestra con el número de referencia 180. PAD 40 también pasa el mensaje RST al controlador de servicio 120, como se muestra con el número de referencia 182.

En respuesta a la recepción del mensaje RST, el controlador de servicio 120 pasa el mensaje RST de regreso a PAD 40 para la certificar la recepción del RST y eliminación exitosa de la sesión TCP, también como se muestra con el número de referencia 182. PAD 40 entonces elimina la máquina de estado 140 de la sesión TCP y envía el mensaje RST a la otra parte de la sesión TCP. Con el fin de promover la operación eficiente de PAD 40 y el controlador de servicio 120, es deseable minimizar la cantidad de mensajes entre ellos. Por consiguiente, PAD 40 solamente envía los últimos mensajes ACK al controlador de servicio 120 si es necesario para abrir una sesión TCP. Además, PAD 40 solamente pasa el primer segmento SYN, FIN recibido en una sesión al controlador de servicio 120. En esta forma, la mensajería en exceso es evitada, aún cuando las funciones de PAD 40 y controlador de servicio 120 estén distribuidos. En una modalidad preferida, PAD 40 necesita solamente mantener la información de estado activa para la sesión TCP para la cual el controlador de servicio 120 configura los servicios de valor agregado. En otras palabras, PAD 40 no mantendrá la información de estado para las sesiones TCP de mejor esfuerzo. Esto reduce enormemente el tamaño de memoria requerido en PAD 40 para mantener la información de estado de TCP (por ejemplo, variables de estado para filtros de encabezado de paquete 90 y monitores 84 y 92). También, ya que existen un gran número de sesiones TCP activas, el mensaje de sesión TCP eliminada dado en el Cuadro III permite al controlador de servicio 120 decidir que sesiones TCP recibirán servicios de valor agregado en el caso en que la memoria de estado de la sesión TCP esté llena. Como se ilustra en la Figura 7B, PAD 40 envía un mensaje de memoria llena de estado TCP 186 al controlador de servicio 120 a través de la inferíase de reporte 102 en respuesta a la detección del evento de estado de memoria llena de TCP 184. El evento de estado de memoria llena 184 puede resultar del agotamiento ya sea del almacenamiento para las variables de estado del filtro de encabezado de paquete o del almacenamiento para las variables de estado del monitor. En respuesta a la recepción del mensaje de estado de memoria llena TCP 186, el controlador de servicio 120 registra el estado de memoria de estado TCP de PAD 40. Cuando el direccionador del cliente 32 inicia otra sesión TCP de valor agregado enviando un mensajes SYN 188, PAD 40 pasa el mensaje SYN al controlador de servicio 120 a través de la interfase de mensajes 100, como se muestra con el número de referencia 190. En respuesta a la recepción del mensaje SYN, el controlador de servicio 120 verifica el estado de la memoria del estado de TCP de PAD 40. Ya que es estado de la memoria del estado de TCP está lleno, el controlador de servicio 120 decide si o no permitir una nueva sesión TCP para sobrescribir las sesiones TCP de valor agregado existentes con base en algunas políticas pre-instaladas. Por ejemplo, el controlador de servicio 120 puede asignar a cada servicio de valor agregado una prioridad y permitir sesiones de prioridad relativa más alta para sobrescribir sesiones TCP de prioridad más baja. Alternativamente, o además, el controlador de servicio 120 puede permitir que la nueva sesión TCP sobrescriba la sesión TCP que tiene el periodo de inactividad más largo. Si a la nueva sesión TCP no se le permite sobrescribir la sesión TCP existente, el controlador de servicio 120 ignora el mensaje SYN. Como un resultado, PAD 40 no instala ninguna información de estado para la nueva sesión TCP, y PAD 40 proporciona servicio de mejor esfuerzo a la nueva sesión TCP. Si, sin embargo, el controlador de servicio 120 decide que la nueva sesión TCP puede sobrescribir otra sesión TCP, el controlador de servicio 120 envía un mensaje de Eliminar sesión TCP 192 a PAD 40 a través de la interfase de control 102. PAD 40 responde eliminando una sesión TCP existente de su memoria de estado TCP, según indicado con el número de referencia 194. El proceso ¡lustrado en la Figura 7A con los números de referencia 150-159 entonces el realizado para instalar la nueva sesión TCP en la memoria de estado de PAD 40. Dada la máquina de estado TCP descrita en la Figura 7A, varios ejemplos de señalización TCP ahora serán descritos con referencia a las Figuras 7C-7G. Haciendo referencia primero a la Figura 7C, se muestra la señalización ilustrativa utilizada para establecer una sesión TCP a través de un sistema de acceso en red de acuerdo con la presente invención. Como se ilustra, para abrir una sesión TCP, una aplicación de cliente primero emite un comando de abrir que informa los datos del protocolo que la aplicación desea para abrir una conexión con un servidor en un puerto especificado y dirección IP (por ejemplo, cuando se accesa una página web). El agente TCP en el sitio del cliente entonces selecciona un número de secuencia inicial (800 en este ejemplo) y transmite un segmento de sincronización (SYN) llenado el número de secuencia seleccionado. Cuando el segmento SYN llega, el filtro de encabezado del paquete 80 en PAD 40 detecta, con base en la dirección IP especificada y número de puerto (PT = 6, Puerto =80), que el segmento SYN pretenden iniciar una sesión TCP de comercio electrónico de misión crítica. Por consiguiente, el filtro de encabezado de paquetes 80 pasa el mensaje SYN a un controlador de servicio de comercio electrónico (ESCS) 120. ESCS 120 responde al segmento SYN buscando en el servidor de políticas 48, por ejemplo, utilizando una solicitud LDAP.

En respuesta al servidor de políticas 48 indicando la aprobación de la sesión TCP, por ejemplo, a través del mensaje de LDAP APROBADO, ECSC 120 regresa el segmento SYN a PAD 40. Cuando PAD 40 recibe el segmento SYN de ECSC 120, PAD 40 reproduce una máquina de estado TCP y la configura en su estado activo 144. PAD 40 entonces envía el segmento SYN corriente abajo al servidor especificado en el segmento SYN. Cuando el segmento SYN es recibido en el servidor, el agente TCP del servidor elige un número de secuencia inicial (400 en este caso) y envía un segmento SYN conteniendo el número de secuencia inicial seleccionada y un ACK a PAD 49. El mensaje ACK especifica que el primer byte de datos enviados por el cliente debería se numerado 801. Se debe observar que mientras los mensajes SYN y ACK enviado por el servidor son enviados por PAD 40 a la aplicación del cliente, estos mensajes no necesitan ser enviados a ESCS 120. Cuando el agente TCP en el cliente recibe el mensaje SYN/ACK, el agente TCP regresa un mensaje ACK de 401, significando que el primer byte de datos enviados por el servidor deberían ser numerados 401. Este mensajes ACK se pasa a través de PAD 40 a ESCS 120 para notificar a ESCS 120 que el apretón de manos de tres direcciones es exitoso y la sesión TCP está abierta. ECSC 120 entonces agrega la sesión TCP en su cuadro de sesión activa y configura PAD 40 con un número permitido de retransmisiones TCP y configuración del cronómetro de inactividad apropiado. ECSC 120 también puede configurar el marcador/vigilante 82 para marcar los paquetes que pertenecen a esta sesión TCP como de alta prioridad. ESCS 120 entonces regresa el segmento ACK a PAD 40, el cual envía el segmento ACK al servidor de destino para informar al receptor que la sesión TCP está abierta. Una vez que el agente TCP del cliente informa a la aplicación del cliente que la conexión TCP está abierta, el cliente y el servidor pueden empezar a intercambiar datos en la sesión TCP. Con referencia ahora a la Figura 7D, se describe un diagrama de tiempo-espacio que ilustra la señalización del sistema de acceso en red ilustrativo para cerrar una conexión TCP de acuerdo con la presente invención. Mientras que cualquier lado de la conexión TCP puede iniciar la desconexión de la sesión TCP, en el ejemplo mostrado en la Figura 7D, la aplicación del servidor inicia el cierre de la sesión TCP, instruyendo a su agente TCP de cerrar la conexión. Por consiguiente, el agente TCP del servidor envía un segmento FIN, informando a la aplicación de cliente que no enviará más datos. En respuesta a la recepción del segmento FIN, PAD 40 reanuda la máquina de estado TCP para la conexión a estado inactivo 142 y pasa el segmento FIN a ESCS 120. ECSC 120 responde eliminando la sesión TCP de su cuadro de sesión activa y configurando PAD 40 para detener los paquetes marcado para esta sesión TCP y para remover el cronómetro de inactividad de la sesión y configuraciones de retransmisión. PAD 40 también envía el segmento FIN al cliente, el cual confirma la recepción del segmento FIN con un ACK que se pasa al servidor a través de PAD 40. La aplicación del cliente entonces de ordena a su agente TCP a cerrar la sesión. El agente TCP del cliente por lo tanto envía un mensaje FIN al agente TCP del servidor a través de PAD 40. El agente TCP del servidor responde al mensaje FIN del cliente con un ACK que indica a PAD 40 que el apretón de manos de tres direcciones para cerrar la sesión TCP es exitoso, PAD 40 por consiguiente elimina la máquina de estado para la sesión TCP y el mensaje ACK a cliente. Mientras tanto, el agente TCP del servidor notifica a la aplicación del servidor que la conexión está cerrada. Haciendo referencia ahora a la Figura 7E, se ilustra un diagrama de tiempo-espacio mostrando señalización del sistema de acceso en red ilustrativo de acuerdo con la presente invención en respuesta a una solicitud de una sesión TCP no autorizada. Como se puede ver a través de la comparación de la Figura 7E con la Figura 7C, el proceso es idéntico hasta que el punto en el cual el servidor de políticas 48 regresa una decisión de política LDAP a ECSC 120 negando la sesión TCP. El servidor de políticas 48 puede negar la sesión TCP, por ejemplo, debido a que la red carece de suficientes recursos para soportar la sesión TCP solicitada o debido a que el cliente no se ha suscrito al servicio de comercio electrónico de prioridad alta solicitado. Después de la negación de la sesión TCP, ECSC 120 emite un segmento (RST) de reanudación a PAD 40, el cual envía el segmento RST corriente arriba al agente TCP del cliente. Cuando el agente TCP del cliente recibe el segmento RST, el agente TCP del cliente aborta la sesión. Se debe observar que debido a que PAD 40 no recibe un segmento SYN de ECSC 120, PAD 40 no crea una máquina de estado para la sesión TCP. Con referencia ahora a la Figura 7F, se ilustra un diagrama de tiempo-espacio mostrando señalización del sistema de acceso en red ilustrativo cuando se detectan retransmisiones TCP excesivas. Como se apreciará, las sesiones TCP son normalmente cerradas a través de una desconexión apropiada, como se ¡lustra en la Figura 7D. Sin embargo, en el caso de una falla de la red o del servidor, la sesión TCP será interrumpida en el huésped y la desconexión normal no ocurrirá. Por consiguiente, algunos mecanismos deben ser implementados para actualizar ECSC 120 y PAD 40 cuando la sesión TCP se desconecta. En el ejemplo mostrado en la Figura 7F, la ruta entre el cliente y el servidor es desestabilizada por la falla de un enlace de red o nodo. Esta falla causa que el agente TCP y el cliente retransmitan los datos hasta que un número de umbral de retransmisiones es alcanzado. El agente TCP del cliente entonces aborta la conexión TCP. Subsecuentemente, el cronómetro de inactividad para la sesión TCP en PAD 40 expira. En respuesta a la expiración del cronómetro de inactividad, PAD 40 actualiza la máquina de estado 140 de la sesión TCP al estado de inactivo 142 y reporta el error de interrupción de la sesión TCP a ECSC 120. ECSC 120 responde al reporte del error de interrupción, eliminando la sesión TCP de su cuadro de sesión activa e instruye a PAD 40 para detener la marcación de paquetes para la sesión TCP y para eliminar la configuración para esta sesión TCP. PAD 40 entonces elimina la máquina de estado para la sesión TCP. Con referencia ahora a la Figura 7G, se describe un diagrama de tiempo-espacio mostrando señalización del sistema de acceso en red ilustrativo cuando una sesión TCP participante solicita un cierre abrupto de la sesión TCP. Como se ilustró, una aplicación, la cual en este caso es la aplicación del servidor, señala un cierre abrupto enviando un segmento de reanudación ( ST). La aplicación puede iniciar el cierre abrupto por un número de razones, por ejemplo, debido a que la aplicación desea abortar la conexión o porque el agente TCP ha detectado un problema de comunicación serio que no puede resolver. En respuesta a la recepción del segmento RST, PAD 40 reanude la máquina de estado TCP 140 para la sesión a un estado inactivo 142 y pasa el segmento RST a ECSC 120. En respuesta a la recepción del segmento RST, ECSC 120 elimina la sesión TCP de su cuadro de sesión activa y configura PAD 40 para detener la marcación de paquetes de su sesión TCP. PAD 40 elimina la máquina de estado TCP de la sesión y envía el segmento RST al cliente. El cliente entonces cierra la sesión TCP una vez recibido el segmento RST.

Ejemplos de Transporte sin Conexión Utilizando la Función de Reportes UDP Con referencia ahora a las Figuras 8A-8C, se describen tres ejemplos de señalización del sistema de acceso en red ilustrativo para protocolos de transporte sin conexión. En cada ejemplo, se emplea el Protocolo de Datagrama Informal (UDP). Haciendo referencia primero a la Figura 8A, se describe un diagrama de tiempo-espacio mostrando señalización del sistema de acceso en red ilustrativo en donde UDP se utiliza como el transporte para datos de voz en una sesión telefónica IP. En el ejemplo ilustrado en la Figura 8A, un cliente ha ordenado un servicio garantizado para sus llamadas telefónicas IP (IPTEL), pero tiene un cliente que no soporta el uso de RSVP para reservar servicio garantizado para las llamadas IPTEL. Sin embargo, el cliente es capaz de obtener servicio garantizado para una llamada IPTEL a través del intercambio de mensajes detallado más adelante. El proceso empieza cuando un cliente en el sitio del cliente invoca una aplicación de cliente para colocar una llamada IPTEL. La aplicación del cliente entonces obtiene un puerto UDP no utilizado de un banco de puertos disponibles asignados para la transmisión de datos de voz. La aplicación del cliente entonces inicia el envío de datos de voz encapsulados a través de paquetes UDP sobre la red como tráfico de mejor esfuerzo. PAD 40, que ha sido configurado para detectar un flujo de paquetes UDP (es decir, Tipo de Protocolo (PT) = 17) dentro del rango del puerto de voz, detecta un flujo UDP y lo reporta al Controlador del Servicio de Telefonía IP (IPTELSC) 120 dentro del procesador externo 42. IPTELSC 120 busca en el servidor de políticas 48 una decisión de política a través de SPI 56, el cual en este ejemplo utiliza COPS. A manera de referencia la base de datos de políticas 46, el servidor de políticas 48 determina que el cliente ha ordenado un servicio garantizado para sus llamadas IPTEL y regresa una decisión de política a IPTELSC 120 que instruye a IPTELSC 120 para proporcionar servicio garantizado para esta sesión IPTEL, según definido por SA, DA, PT = 17, SP y DP. IPTELSC 120 por consiguiente configura PAD 40 con un cronómetro de inactividad para la sesión e instruye a PAD 40 para detener el reporte de ocurrencias de esta sesión IPTEL. IPTELSC 120 también inicia la configuración de una ruta de ancho de banda reservada para la llamada IPTEL ya que la aplicación del cliente es incapaz de hacer esto. Para configurar la ruta de ancho de banda reservada, IPTELSC 120 envía un MENSAJE RSVP PATH a PAD 40, el cual envía el MENSAJE PATH corriente abajo al receptor. Para indicar la aprobación de la reservación, asi como la cantidad de ancho de banda reservado, el receptor envía un mensaje de RESV a PAD 40, el cual envía el mensaje RESV a IPTELSC 120. Entonces se hace una determinación de si una reservación del ancho de banda especificado es autorizada. Si IPTELSC 120 tiene ocultada suficiente información de políticas después de la búsqueda del servidor de políticas 48, IPTELSC 120 no necesita buscar el servidor de políticas 48 con respecto al ancho de banda. Si, sin embargo, se ha ocultado información de política insuficiente, en la memoria de políticas 130 de IPTELSC 120, el servidor de políticas 48 otra vez es investigado para ver si se puede reservar el ancho de banda especificado. Si el ancho de banda especificado está disponibles para reservación para este cliente, IPTELSC 120 inicia la señalización a través de un controlador de señalización 120 para configura ya sea un SVC o LSP para la sesión IPTEL. Para un núcleo ATM, se configura un SVC bidireccional. Alternativamente, para un núcleo MPLS, se configuran dos LSPs unidireccionales. Otros medios para proporcionar QoS a esta sesión UDP involucra al marcador de instrucciones 82 de IPTELSC 120 en PAD 40 a modificar el campo servicio diferenciado (DiffServ) en el encabezado de IP. Una vez que IPTELSC 120 recibe una conexión o confirma el mensaje de la red indicando que la trayectoria QoS ha sido establecida, IPTELSC 120 actualiza PAD 40 para asociar el flujo de paquetes UDP con la trayectoria QoS. Además, IPTELSC 120 confirma que la trayectoria QoS está configurada y reservada pasando un mensaje de confirmación a PAD 40, el cual pasa el mensaje de confirmación al receptor. Por lo tanto, los datos de voz encapsulados en paquetes UDP son enviados desde la aplicación del cliente al receptor a través de la trayectoria QoS. Como se muestra en la Figura 8B, en el caso en que la búsqueda en el servidor de políticas 48 resulte en una decisión de política indicando que el cliente no tiene un requerimiento de QoS para llamadas IPTEL, IPTELSC 120 configura PAD 40 para prevenir que PAD 40 reporte la llamada IPTEL otra vez. Además, IPTELSC 120 configura un cronómetro de inactividad para la llamada IPTEL para que la prevención del reporte de llamada pueda ser eliminado cuando el cronómetro de inactividad expire. Debido a que ninguna trayectoria QoS está autorizada, los datos de voz encapsulados a través de paquetes UDP continúan siendo transmitidos sobre la red como tráfico de mejor esfuerzo. Con referencia ahora a la Figura 8C, se muestra un diagrama de tiempo-espacio que ilustra señalización de sistema de acceso en red utilizado para tirar una trayectoria QoS en respuesta a la expiración de un cronómetro de inactividad de sesión UDP. Mientras un cronómetro de inactividad de sesión UDP puede expirar por un número de razones incluyendo la falla de una Ifnea o nodo de red, en el ejemplo ilustrado en la Figura 8C, el evento interrumpido es causado por la aplicación del cliente en el sitio del cliente concluyendo una llamada y cesando la transmisión del tráfico de voz. Algún tiempo después, cuando el cronómetro de inactividad de la sesión UDP expira, PAD 40 detecta el evento interrumpido y lo reporta a IPTELSC 120. IPTELSC 120 responde iniciado señalización apropiada para liberar la SVC o LSPs para la llamada IPTEL, y la liberación se confirma a través de un mensaje a IPTELSC 120. IPTELSC 120 también invoca el mensaje de tirar trayectoria para explícitamente tirar la trayectoria QoS para la llamada IPTEL. Mientras este mensaje es pasado de PAD 40 a través de la red, el mensaje de tirar trayectoria remueve los estados RSVP instalados junto con la trayectoria QoS. IPTELSC 120 entonces elimina la llamada IPTEL de su cuadro de sesión activa y configura PAD 40 para eliminar todos los parámetros configurados para la llamada IPTEL.

Ejemplos de Aplicación de Nivel Utilizando Señalización SIP Haciendo referencia a hora a las Figuras 9A-9E, se ilustra un número de diagramas tiempo-espacio mostrando la señalización SIP de aplicación de nivel en un sistema de acceso en red de acuerdo con la presente invención. Haciendo referencia primero a la Figura 9A, se muestra el establecimiento de una llamada SIP. En el ejemplo ilustrado, un llamador en el sitio del cliente emite una solicitud INVITAR SIP para solicitar una llamada en la red, por ejemplo, para invitar al llamador a participar en una llamada de conferencia de multimedia. Cuando PAD 40 detecta la solicitud de invitación a través de UDP o el rango de puerto TCP asignado a SIP, PAD 40 pasa la solicitud de INVITAR a un Controlador de Servicio de Llamadas de Conferencia (CCSC) 120. CCSC 120 entonces busca el servidor de políticas 48 (por ejemplo, utilizando una solicitud LDAP) con respecto a si la capacidad solicitada es aprobada para el cliente. Importantemente, para reducir el número de intercambio de mensajes entre CCSC 120 y el servidor de políticas 48, CCSC 120 preferiblemente fija una bandera en la búsqueda para solicitar que el servidor de políticas descargue las búsquedas de política para la solicitud SIP en la memoria de políticas 130 de CCSC 120. En esta forma, CCSC 120 puede por lo tanto tomar decisiones de políticas con referencia a las políticas memorizadas y evitar búsquedas innecesarias del servidor de políticas 48. Asumiendo que el servidor de políticas 48 aprueba la sesión SIP, el servidor de políticas 48 envía a CCSC 120 una decisión de política indicando la aprobación de la sesión SIP y descarga las reglas de las políticas para SIP llamándolas en la memoria de políticas 130 de CCSC 120. En respuesta a la recepción de la aprobación de la sesión SIP, CCSC 120 regresa el mensaje INVITAR a PAD 40, el cual envía la solicitud INVITAR hacia el llamador. En respuesta a la recepción de la solicitud INVITAR, el llamador regresa un mensaje OK SIP 200 a PAD 40, por lo tanto indicando la aceptación de la llamada sin cambio en la capacidad SIP especificada. Debido a que no hay cambio en la capacidad SIP, PAD 40 envía el mensaje OK SIP 200 directamente al llamador no pasa a través del mensaje a CCSC 120. El llamador entonces confirma la aceptación del mensaje OK SIP 200 a través de una solicitud ACK, la cual PAD 40 pasa a CCSC 120 para informar el establecimiento exitoso de la sesión SIP. CCSC 120 entonces busca en su memoria de políticas 130 para aprobar la configuración de capacidad final de la llamada SIP. CCSC 120 también agrega la sesión SIP en su cuadro sesión activa y configura PAD 40 con un cronómetro de inactividad y otros parámetros para facilitar la llamada SIP. CCSC 120 entonces regresa la solicitud ACK a PAD 40, el cual a su vez envía la ACK al llamador para completar el establecimiento de la llamada SIP. Para obtener un mejor funcionamiento, es deseable minimizar el mensaje pasándolo de PAD 49 a CCSC 120 y de CCSC 120 al servidor de políticas 48. Como se discutió anteriormente, las reglas de memoria de políticas en CCSC 120 reducen enormemente el número de búsquedas de políticas requeridas. Al pasar el mensaje de PAD 40 a CCSC 120 es preferiblemente también reducir a través de la ¡mpiementación de una máquina de estado SIP a PAD 40 que pasa mensajes SIP a CCSC 120 solamente para establecer, terminar o cambiar la capacidad de configurar una sesión SIP. Con referencia ahora a la Figura 9B, se muestra un diagrama de tiempo-espacio que ilustra la señalización del sistema de acceso en red ilustrativo para la terminación de una llamada SIP. En una llamada de conferencia SIP de multipartes, cada parte solamente puede desconectarse a si mismo de la llamada, y la llamada es terminada después de que la última parte deja la llamada. En contraste, en una llamada SIP de dos partes, como se ilustra en la Figura 9B, ya sea el llamador o a la persona que se le llama pueden terminar la llamada. Como se muestra en la Figura 9B, el llamador en el sitio del cliente inicia la terminación de la llamada enviando una solicitud BYE, la cual PAD 40 pasa a CCSC 120. CCSC 120 responde a la solicitud BYE eliminando la sesión SIP de su cuadro de sesión activa y limpiando su memoria de políticas 130 del servidor de políticas pertenecientes a la sesión SIP. CCSC 120 entonces configura PAD 40 para prevenir PAD 40 de pasar subsecuentes mensajes SIP de la llamada SIP a CCSC 120 y para eliminar a configuración completa de la llamada SIP. CCSC 120 también envía BYE a PAD 40, el cual envía la solicitud BYE a la persona que se le llama. En respuesta la recepción de la solicitud BYE, la persona a la que se le llama confirma la finalización de la llamada SIP enviando un mensaje OK SIP 200, el cual PAD 40 envía al llamador sin pasar a CCSC 120. Haciendo referencia ahora a la Figura 9C, se ¡lustra un diagrama tiempo-espacio mostrando señalización del sistema de acceso en red ilustrativo que ha excedido la duración permitida. En el ejemplo descrito, la terminación de una llamada SIP es activada a través de CCSC 120 detectando que la llamada SIP ha excedido la duración permitida especificada por la expiración del cronómetro de la sesión. La persona que recibe la llamada emite una solicitud de BYE para terminar la llamada. En respuesta a la recepción de la solicitud BYE, PAD 40 pasa la solicitud BYE a CCSC 120, CCSC 120 la elimina la sesión SIP de su cuadro de sesión activa y remueve las políticas asociadas en su memoria de políticas 130. CCSC 120 entonces configura PAD 40 para prevenir que PAD 40 siga pasando a CCSC 120 mensajes SIP subsecuentes en la llamada SIP y le ordena a PAD 40 que elimine la configuración completa de la llamada SIP. CCSC 120 entonces emite una solicitud BYE a PAD 40, la cual envía la solicitud BYE a ambos, el llamador y la persona que recibe la llamada. El llamador y la persona que recibe la llamada entonces confirman la finalización de la sesión SIP a través de un mensaje OK SIP 200. La Figura 9D ilustra un ejemplo de terminación de una tercera llamada en donde ninguna de las partes solicita una terminación de llamada, sino en su lugar, ambas partes simplemente tiran la sesión SIP. En ausencia de la actividad en la sesión SIP, el cronómetro de inactividad en PAD 40 para la llamada SIP expira. PAD 40 entonces reporta una interrupción a CCSC 120, la cual elimina la sesión SIP de su cuadro de sesión activa y remueve las políticas asociadas de su memoria de políticas 130. CCSC 120 entonces ordena a PAD 40 que elimine la configuración completa de la llamada SIP. Haciendo referencia ahora a la Figura 9E, se describe un diagrama tiempo-espacio mostrando señalización del sistema de acceso en red ilustrativo durante la negociación de los requerimientos de capacidad de la llamada SIP entre un llamador y la parte que recibe la llamada. Como se describió anteriormente con respecto a la Figura 9A, una llamada SIP es iniciada a través de una aplicación del cliente en el sitio de cliente emitiendo una solicitud de INVITAR SIP. Esta solicitud de INIVITAR se captura por parte de PAD 40 y se pasa a CCSC 120, la cual busca en el servidor de políticas 48. El servidor de políticas 48 responde con una aprobación de la llamada SIP y una descarga de las reglas de políticas para esta sesión SIP (según solicitado en la búsqueda de políticas). CCSC 120 entonces devuelve la solicitud INVITAR a PAD 40, el cual la envía a la parte que recibe la llamada. Sin embargo, en contraste al ejemplo ilustrado en la Figura 9A, la parte que recibe la llamada no responde a un mensaje de OK de SIP 200 confirmando la llamada SIP. Más bien, la parte que recibe la llamada responde con un mensaje de NO ACEPTABLE SIP 606 indicando que la anchura de banda de llamada solicitada es mayor que aquella con la cual puede ser soportada por el enlace de acceso de la parte que recibe la llamada y que sólo está disponible una conexión de 56 Kbps. Como fue solicitado por la solicitud de INVITAR, la respuesta de la parte que recibe la llamada además indica un grupo de codificaciones de medios, por ejemplo, que sólo PCM (modulación de código de pulso) o audio de codificación de predicción (LPC) puede ser soportado (en ese orden de preferencia). En respuesta a la recepción del mensaje de NO ACEPTABLE SIP 606, PAD 40 pasa el mensaje a CCSC 120, que pide su memoria de políticas 130 y aprueba el nuevo gripo de capacidades. CCSC 120 después envía el mensaje de NO ACEPTABLE SIP 606 de regreso a PAD 40, que pasa el mensaje a la parte que llama. Cuando la parte que llama recibe la respuesta de NO ACEPTABLE SIP 606, la parte que llama ajusta los requerimientos de capacidad y emite otra solicitud de INVITAR especificando una anchura de banda de 56 Kbps, codificación de audio LPC y Cronómetro de Expiración de 120 minutos. Como antes, la nueva solicitud de INVITAR se pasa a CCSC 120 a través de PAD 40. CCSC 120 después solicita su memoria de políticas local 130 y limita la duración de la llamada a 100 minutos de acuerdo con la disponibilidad de recursos. CCSC 120 después regresa la solicitud de INVITAR al Cronómetro de Expiración de 100 minutos a PAD 40, que envía la solicitud de INVITAR a la parte que recibe la llamada. En respuesta a la recepción de esta segunda solicitud de INVITAR, la persona que recibe la llamada determina que es capaz de soportar todos los requerimientos de la llamada incluyendo la duración de la llamada de 100 minutos. Por consiguiente, la parte que recibe la llamada responde con un mensaje OK SIP 200 que tiene un cronómetro de expiración fijado en 100 minutos. En respuesta a la recepción del mensaje OK SIP 200, PAD 40 envía la respuesta a CCSC 120, el cual verifica la capacidad fijada llevada en la respuesta la respuesta OK SIP a través de la referencia a su memoria de políticas 130 y la aprueba. CCSC 120 entonces envía la respuesta OK SIP a PAD 40, el cual envía la respuesta OK SIP al llamador. Cuando el llamador recibe la respuesta OK SIP, el llamador modifica la expiración del cronómetro en 100 minutos y confirma la respuesta OK SIP a través de una solicitud ACK. PAD 40 pasa la respuesta ACK a CCSC 120, el cual aprueba la capacidad fijada llevad por SIP final en la respuesta ACK. Enseguida a esta aprobación, CCSC 120 configura PAD 40 con un cronómetro de inactividad y otros parámetros para facilitar la llamada SIP. CCSC 120 también regresa el mensaje ACK a PAD 40, el cual envía el mensaje ACK a la parte que recibe la llamada. Una vez la recepción de la respuesta ACK a través del llamador, la llamada SIP es exitosamente establecida.

Ejemplos de Multidif usión IP Como implementó en las redes actuales, la multidifusión IP, que es, la entrega de paquetes a dos o más receptores, emplea un modelo de "grupo abierto" de comunicación. De acuerdo con el modelo de grupo abierto, las fuentes necesitan solamente conocer una dirección de multidifusión a la cual enviar los paquetes, pero no necesitan conocer la membresía de un "grupo" participante en una sesión de multidifusión y/o pertenecer al grupo de multidifusión al cual están enviando los paquetes de multidifusión. Además, no existe una entidad de administración del grupo centralizada con la cual el los miembros del grupo necesitan registrase, sincronizar, o negociar, significando que los miembros del grupo de multidifusión pueden unirse o dejar un grupo de multidifusión cuando quieran. Aunque el modelo de grupo abierto actual de comunicación de multidifusión o control de comunicación de multidifusión, administración y control de membresía de grupo de multidifusión es importante para ambos, el que remitentes y receptores. Para los remitentes, es importante que solamente las fuentes autorizadas estén disponibles para enviar paquetes a grupos de multidifusión. Por ejemplo, los proveedores de contenido por lo general desean proteger su exclusividad como la única fuente de datos para un grupo de multidifusión y desean evitar ataques de negación de servicio debido a inundaciones de fuentes no autorizadas. Asimismo es importante para la configuración de los receptores en un grupo multidifusión ser controlado para restringir la recepción de paquetes a partes autorizadas a través de las fuentes. Como un ejemplo, las fuentes desean restringir la capacidad de los receptores de recibir distribución de videos y paquetes de multidifusión de conferencias de video. Si la vista de los defectos en el modelo de grupo abierto de multidifusión IP mencionado anteriormente, la arquitectura del sistema de acceso en red de la presente invención implementa la administración del servicio de multidifusión con base en políticas como se ilustra en las Figuras 10A-10H. Haciendo referencia primero a las Figuras 10A-10B, se describe dos diagramas de tiempo-espacio mostrando la señalización del sistema de acceso en red ilustrado para manejar el registro de nuevos grupos de multidifusión de acuerdo con la presente invención. Como se muestra en la Figura 10A, un huésped en el sitio del cliente señala un deseo de unirse a un grupo multidifusión (el cual puede ser un nuevo grupo de multidifusión) enviando un Mensaje de Reporte de Unión a Grupo de Protocolo de Multidifusión de Grupo (IGMP) al direccionador de acceso 44 a través de PAD 40. El filtro de encabezado de paquetes 80 de PAD 49, el cual está configurado para capturar mensajes IGMP examinando el tipo de protocolo (PT = 2), envía el Mensaje de Reporte de Unión a Grupo al Controlador de Servicio de Multidifusión (MSC) 120 en el procesador externo 42. En respuesta a la recepción del Mensaje de Reporte de Unión a Grupo, MSC 120 busca en el servidor de políticas 48 a través de SPI 56, el cual en este caso emplea LDAP. El servidor de políticas 48 responde a la búsqueda buscando en la base de datos de políticas 46 para determinar se la dirección IP del huésped pertenece a una lista de membresía elegible para el grupo de multidifusión. Como se muestra en la Figura 10B, si el servidor de políticas 48 determina que el huésped no es elegible para unirse a un grupo de multidifusión, el servidor de políticas 48 regresa una decisión de política a MSC 120 rechazando la solicitud de Unión a Grupo. MSC 120 responde al rechazo de la solicitud tirando el Mensaje de Unión a Grupo que previene que el huésped no autorizado siga registrando un nuevo grupo multidifusión en el direccionador de acceso 44. MSC 120 también puede escribir el intento no autorizado en un registro de eventos para uso en la detección de intentos de fraude o negar los ataques al servicio. Alternativamente, si el servidor de políticas 48 aprueba la solicitud del huésped para unirse al grupo de multidifusión especificado, como se muestra en la Figura 10A, el servidor de políticas 48 envía una decisión de política indicando la aprobación a MSC 120, el cual regresa el Mensaje de Reporte de Unión a Grupo a PAD 40. PAD 40 entonces envía el Mensaje de Reporte de Unión a Grupo al direccionador de acceso 44. Si el huésped es el primer miembro del grupo de multidifusión en la red, el direccionador de acceso 44 agrega el grupo de multidifusión reportado en el Mensaje de Reporte de Unión a Grupo a la lista de membreslas del grupo de multidifusión en la red a la cual el huésped está unido. Haciendo referencia ahora a la figura 10C se describe un diagrama de espacio-tiempo ilustrando señalización del sistema de acceso en red ilustrativo que es utilizado para manejar las búsquedas de investigaciones de membresía del huésped para determinar la membresía de un grupo multidifusión. En el ejemplo mostrado en la Figura 10C, PAD 40 recibe un mensaje de Búsqueda de Membresía de Huésped IGMP originado en la red desde el direccionador de acceso 44. El filtro de encabezado de paquetes 80 captura este mensaje IGMP con base en su número de puerto y pasa el Mensaje de Búsqueda de Membresía de Huésped a MSC 120 en el procesador externo 42. MSC 120 entonces busca en el servidor de políticas 48 a través de SPI 56 (el cual en este ejemplo emplea LDAP) para cerciorarse de si la dirección de la fuente del Mensaje de Búsqueda de Membresía del Huésped es un direccionador de acceso autorizado 44. Como se muestra en la Figura 10B, si el servidor de políticas 44 a través de la referencia a la base de datos de políticas 46 que el mensaje de Búsqueda de Membresía del Huésped es de una fuente no identificada o no autorizada, el servidor de políticas 48 regresa una decisión de política a MSC 120 rechazando la Búsqueda de Membresía del Huésped. En respuesta al rechazo de la Búsqueda, MSC 120 tira el mensaje de Búsqueda de membresía del Huésped y escribe un mensaje de advertencia en este registro del evento que puede indicar una negación del servicio dirigido hacia la red inundando de mensajes de Búsqueda de Membresía de Huésped no autorizado. Si, por el otro lado, el servidor de políticas 48 aprueba la Búsqueda de la Membresía del Huésped y de esta manera indica a MSC 120, como se muestra en la Figura 10C, la Búsqueda de la Membresía del Huésped es regresada a PAD 40, el cual envía la Búsqueda de la Membresía del Huésped a los huéspedes en el sitio del cliente. De esta forma, el sistema de acceso en red de la presente invención soporta la administración con base en políticas las Búsquedas de la Membresía del Huésped. Con referencia ahora a las Figuras 10E-10F, se describen diagramas de tiempo-espacio de señalización de sistema de acceso en red ilustrativo utilizado para manejar el envío de paquetes de multidifusión a la red. En los ejemplos mostrados en ambas, Figuras 10E-10F, un huésped en el sitio del cliente envía paquetes multidifusión de IP dirigidos a un grupo de multidifusión particular. Cuando PAD 40 recibe el primer paquete de multidifusión, el filtro de encabezado de paquetes 80 captura el paquete después de verificar, para determinar si los paquetes que tienen su dirección de multidifusión han sido previamente recibidos. PAD 40 entonces pasa el primer paquete de multidifusión a MSC 120 en el procesador externo 42. MSC 120 busca en el servidor de políticas 48 a través de SIP 56 (el cual en este caso emplea LDAP) para determinar si la dirección fuente del paquete de multidifusión es autorizada para enviar los paquetes de multidifusión a un grupo de multidifusión especificado. Como se muestra en la Figura 10F, en respuesta a la recepción de una decisión de política rechazando el envío del paquete de multidifusión (por ejemplo, debido a que la fuente que está enviando el paquete de multidifusión es no identificada o no autorizada), MSC 120 configura PAD 40 para tirar los paquetes de multidifusión para esta combinación de dirección de fuente y multidifusión y escribe un mensaje de advertencia en el registro de eventos que puede indicar un intento de negación del servicio a través de una fuente particular inundando de paquetes multidifusión en la red. Alternativamente, si MSC 120 recibe una decisión de política del servidor de políticas 48 aprobando el paquete de multidifusión como se muestra en la Figura 10E, MSC 120 configura PAD 40 para directamente enviar los paquetes de multidifusión para esta combinación de dirección de fuente y multidifusión al direccionador de acceso 44 y regresa el primer paquete de multidifusión a PAD 40. PAD 40 entonces envía el primer paquete de multidifusión a direccionador de acceso 44 y envía todos los paquetes de mu Itid ¡fusión subsecuentes en el flujo directamente al d ireccionador de acceso 44, sin pasarlos a MSC 120. De esta forma, el sistema de acceso en red de la presente invención utiliza decisiones con base en políticas para permitir el ingreso de paquetes de multidifusión autorizados y prevenir el ingreso de paquetes no autorizados. Con referencia ahora a las Figuras 10G-10H, se ilustran diagramas de tiempo-espacio de señalización del sistema de acceso en red ilustrativo para manejar la recepción de paquetes de multidifusión desde la red. En el ejemplo mostrado en las Figuras 10G y 10H, el direccionador de acceso 44 recibe paquetes de multidifusión de IP desde la red y los envía a PAD 40. En respuesta a la recepción del primer paquete de multidifusión, el filtro de encabezado de paquetes 90 de PAD 40 captura el paquete de multidifusión después de verificarlo para determinar si un paquete que tiene su dirección de multidifusión ha sido previamente recibido. El filtro de encabezado de paquetes 90 entonces pasa el primer paquete de multidifusión a MSC 120 en el procesador externo 42, el cual busca en el servidor de políticas 48 para determinar si la dirección de la fuente de la dirección de multidifusión está autorizada para enviar paquetes de multidifusión a grupos de multidifusión especificados. Como se muestra en la Figura 10H, si el servidor de políticas 48 que recibe los paquetes de multidifusión es no autorizado, por ejemplo, debido a que la fuente de los paquetes de multidifusión es no identificada o no autorizada, el servidor de políticas 48 envía a MSC 120 una decisión de política rechazando la recepción del paquete de multidifusión. En respuesta al rechazo de la recepción del paquete de multidifusión, MSC 120 configura PAD 40 para tirar los paquetes de multidifusión para esta combinación de dirección de fuente y de multidifusión y escribe un mensaje de advertencia en el registro de eventos que puede indicar paquetes de multidifusión no autorizados de un intento de dirección de fuente especificada para inundar la sub-red en el sitio del cliente. Como un resultado, los paquetes de multidifusión subsecuentes conteniendo la misma combinación de fuente y dirección de multidifusión son tirados por PAD 40. Alternativamente, como se muestra en ia Figura 10G, si el servidor de políticas 48 aprueba la recepción del paquete de multidifusión, MSC 120 configura PAD 40 para directamente enviar paquetes subsecuentes conteniendo la misma combinación de fuente y dirección de multidifusión directamente al sitio de cliente. MSC 120 regresa el primer paquete de multidifusión a PAD 40, el cual envía el primer paquete de multidifusión y paquetes de multidifusión subsecuentes al sitio del cliente. Como se ilustra en la Figura 10H, los paquetes de multidifusión subsecuentes en el flujo son enviados a través de PAD 40 directamente al sitio del cliente sin pasarlos a MSC 120.

Conclusión Como se ha descrito, la presente invención introduce una arquitectura de sistema de acceso en red distribuida. La arquitectura del sistema de acceso en red distribuida de la presente invención reemplaza un direccionador de borde monolítico convencional con un dispositivo de acceso programable conteniendo por lo menos una funcionalidad de filtrado y envío, un procesador externo que tiene uno más controladores de servicio específicos de servicio que implementan el control con base en políticas de PAD, y un direccionador de acceso que realiza direccionamiento básico. La arquitectura distribuida tiene numerosos beneficios sobre las arquitecturas del direccionador monolítico, incluyendo escalabilidad, flexibilidad, extensibilidad, interoperabilidad, seguridad y aprovisionamiento de servicio. La arquitectura del acceso en red de la presente invención logra una escalabilidad superior según comparada con los direccionadores monolíticos a través de la virtud de la distribución de funcionalidad entre tres módulos lógicos: un dispositivo de acceso programable, un procesador externo proporcionando control de servicio, y un direccionador de acceso. En particular, separando el direccionamiento llevado a cabo por el direccionador de acceso desde la funcionalidad implementada por el dispositivo programable y procesador externo, tráfico adicional y los servicios pueden ser manejados sin sobrecargar el direccionador de acceso simplemente agregando módulos de procesador externo y dispositivos de acceso programables de acuerdo al los requerimientos de servicio y demanda del cliente. Además, ya que los patrones del tráfico en Internet continúan para cambiar desde localmente concentrados a globalmente distribuidos, la habilidad para aplicar el servicio y control de políticas en el punto de acceso de la red separadamente desde direccionadores regionales proporcionan un diseño más escalable para enviar tráfico hacia destinos distantes. La arquitectura del sistema de acceso en red distribuido de la presente invención también proporciona flexibilidad mejorada. Dicha flexibilidad en un sobrecrecimiento natural de la habilidad de un proveedor de servicio y/o cliente para implementar políticas que gobiernen el control del servicio y programabilidad de módulos funcionales del dispositivo de acceso programable. Por ejemplo, los filtros de encabezado de paquetes del dispositivo de acceso programable pueden ser configurados para distinguir flujos de paquetes con base en cualquier combinación arbitraria de SA, DA, TOS/DSCP, PT, SP y DP, así como información de protocolo de capa más alta, tales como TCP, SIP y IGMP. Además, los monitores del dispositivo de acceso programable pueden ser programados a través de los controladores de servicio del procesador externo para recolectar estadísticas para combinaciones arbitrarias de SA, DA, TOS/DSCP, PT, SP, DP, y otros campos y para reportar sobre eventos (por ejemplo, retransmisiones TCP excesivas, e inactividad RTP/UDP) con base en las estadísticas recolectadas. Una aplicación particularmente útil de dicho monitoreo es el rastreo de estadísticas para diferentes tipos de tráfico de capa 2, capa 3, capa 4 y capas más altas para asegurar que las SLAs activas son mantenidas a través de la red. Este enfoque basado en políticas para proveer soporte SLA dinámico en la red es una solución más flexible que el enfoque TDM actual (Multiplexión de División de Tiempo) a SLAs. La ventaja de la extensibilidad se origina en parte debido a control de servicio específico provisto a través de los controladores de servicio en el procesador externo. Dicho control de servicio específico puede ser implementado ya sea con controladores de servicio dedicados o con controladores genéricos que cada uno soporta APIs de servicio específico. Con respecto a la implementación seleccionada, pueden ser introducidos nuevos servicios agregando nuevos controladores de servicio o modificando controladores de servicio existentes. La adición de nuevos servicios no necesita ninguna alteración al dispositivo de acceso programable, direccionador de acceso, u otros controladores de servicio. De esta forma, otros servicios no son interrumpidos durante la actualización del servicio. Además, debido a que los controladores de servicio son independientes del dispositivo de acceso programable y direccionador de acceso, el desarrollo de nuevos servicios y actualización de servicios existentes no depende de los vendedores de hardware de propietario, los cual reduce enormemente el tiempo y el costo para desarrollar o actualizar los servicios. La extensibilidad de la presente invención también es atribuible a las funciones de monitoreo adicionales que pueden ser implementadas en el dispositivo de acceso programable, por ejemplo, para verificar la conformación a estándares, código de depuración, y diagnosis de falla de asistente guardando y reportando caídas de memoria y otra información relacionada con los controladores de servicio, Dicha capacidad no está integrada en los interruptores convencionales o direccionadores y usualmente se logra solamente a través de la adición de dispositivos de monitoreo en red externos. El monitoreo de uso mejorado provisto por la presente invención habilita a un proveedor de servicios a vender recursos de red (es decir, capacidad) dinámicamente mientras aún conforman las SLAs. Esto no solamente mejora la utilización de la red, sino que automatiza la ingeniería de tráfico, lo cual reduce los gastos de administración de la red. Como se mencionó anteriormente, el sistema de acceso en red distribuido de la presente invención distribuye funcionalidad de acceso en red entre un dispositivo de acceso programable, un procesador externo proporcionando control de servicio, y un direccionador de acceso. Debido a que estos diferentes componentes se comunican a través de interfases bien definidas, la interoperabilidad no depende de todos los componentes de hardware o software que están siendo desarrollados por el mismo vendedor. La presente invención también proporciona seguridad mejorada contra robo de servicios y ataques de red. Por ejemplo, el procesador externo puede ser mantenido en una ambiente seguro mientras deja las funciones de envío del dispositivo de acceso programable en un ambiente menos seguro. Además, el software y/o hardware de seguridad puede ser fácilmente integrado en el procesador externo para que las sesiones para configurar el dispositivo de acceso programable desde las direcciones IP diferente de sus procesadores externos maestros (así como otra comunicación no autorizada) son negados por el filtro de encabezado de paquetes del dispositivo de acceso programable sin ser pasados en la red. La presente invención también tiene aprovisionamiento de servicio mejorado. Ya que el dispositivo de acceso programable intercepta los mensajes de nivel de red, transporte y aplicación, de esta forma habilitando la identificación de aplicaciones y usuarios, el sistema de acceso en red de la presente invención puede establecer prioridades apropiadas para o proporcionar un ancho de bada deseado para los flujos de datos de aplicaciones de usuarios. Por ejemplo, empleando RSVP o administrador de ancho de banda de subred LAN (SBM), una aplicación del cliente puede ser provista con ancho de banda garantizado y prioridad de principio a fin a través de redes locales y de área amplia. Importantemente, las políticas que habilitan las aplicaciones de clientes para reservar ancho de banda, llevan a cabo control de admisión, y corrientes de tráfico priorizadas con base en la capacidad de red disponible que puede ser determinada no solamente a través del proveedor del servicio sino también por los clientes. De esta forma, las aplicaciones de los clientes pueden interactuar con los recursos de red de proveedor de servicio para dinámicamente proveer servicios y proveer aplicaciones con calidad garantizada de calidad de servicio. Este aprovisionamiento con base en la red invocado por el control de políticas reemplaza el consumo de tiempo y aprovisionamiento OSS (Sistema de Operación y Soporte) propenso a error, y de esta forma reduciendo la intensidad y el costo del aprovisionamiento de la red para aplicaciones de clientes de IP céntricas. Aún con las ventajas anteriores, la arquitectura del sistema de acceso en red distribuido de la presente invención puede proporcionar una solución de red de costo efectivo. Actualmente, la tendencia es para proveedores de servicio para que empujen de manera más "inteligente" y por lo tanto dispositivos más costosos al borde de sus diseños de red. Sin embargo, este diseño requiere de clientes que compren CPEs (Equipo de Premisas del Cliente) inteligentes y costosos. En contraste, la arquitectura del sistema de acceso en red distribuido de la presente invención soporta PADs no costosas relativamente, que permiten a los clientes a comprar inteligencia suficiente para proveer suministro de servicios sin gastos indebidos. Ya que la invención ha sido mostrada y descrita con referencia a una modalidad especifica, se entenderá por aquellos expertos en la técnica que varios cambios en forma y detalle pueden ser hechos sin apartarse del espíritu y alcance de la invención. Por ejemplo, aunque los aspectos de la presente invención han sido descritos con respecto a un sistema de computadora ejecutando software que dirige las funciones de la presente invención, se debe entender que la presente invención puede alternativamente ser implementada como un producto de programa para uso con un sistema de procesamiento de datos. Los programas definiendo las funciones de la presente invención pueden ser suministrados a un sistema de procesamiento de datos a través de una variedad de medios de soporte de señales, que incluyen, sin limitación, medios de almacenamiento no re-escribibles (por ejemplo, CD-ROM), medios de almacenamiento re-escribibles (por ejemplo, disquete flexible o unidad de disco duro), y medios de comunicación, tales como redes digitales o análogas. Se debe entender, por lo tanto, que dichos medios de soporte de señales, cuando llevan o codifican instrucciones legibles por computadora que dirigen las funciones de la presente invención, representan modalidades alternativas de la presente invención.

Claims (39)

REIVINDICACIONES

1. Un método de comunicación en un sistema de acceso en red incluyendo un procesador externo y un dispositivo de acceso programable, dicho método comprendiendo: transmitir un mensaje de control desde el procesador externo al dispositivo de acceso programable para establecer una configuración del dispositivo de acceso programable; y comunicar mensajes desde el dispositivo de acceso programable al procesador externo para procesamiento del servicio de acuerdo con la configuración.

2. El método de acuerdo con la reivindicación 1, en donde: transmitir un mensaje de control comprende transmitir un mensaje de control de filtro para establecer una configuración de un filtro de encabezado de paquete en el dispositivo de acceso programable; y comunicar mensajes que comprenden comunicar mensajes de red filtrados desde un flujo de paquete a través del filtro de encabezado de paquete del dispositivo de acceso programable.

3. El método de acuerdo con la reivindicación 2, y además comprende limitar la comunicación de mensajes de red desde el dispositivo de acceso programable al procesador externo, enviando al dispositivo de acceso programable un mensaje configurando las banderas de interfase de mensaje en el dispositivo de acceso programable.

4. El método de acuerdo con la reivindicación 1, en donde: la transmisión un mensaje de control comprende transmitir un mensaje de control de monitor para establecer una configuración de un monitor en el dispositivo de acceso programable; y comunicar mensajes que comprenden comunicar mensajes de reporte desde el dispositivo de acceso programable al procesador externo en respuesta a la configuración del monitor.

5. El método de acuerdo con la reivindicación 4, en donde transmitir un mensaje de control de monitor comprende transmitir un mensaje de control para establecer un número de umbral de retransmisiones permitidas.

6. El método de acuerdo con la reivindicación 1, en donde transmitir un mensaje de control de monitor comprende transmitir un nivel de actividad de umbral.

7. El método de acuerdo con la rei indicación 1, en donde transmitir un mensaje de control comprende transmitir un mensaje de control de vigilante para establecer una configuración de un vigilante en el dispositivo de acceso programable.

8. El método de acuerdo con la reivindicación 1, en donde un mensaje de control comprende transmitir un mensaje de control de cuadro de envíos para establecer una configuración de un cuadro de envíos en el dispositivo de acceso programable.

9. El método de acuerdo con la reivindicación 8, en donde establecimiento de una configuración de un cuadro de envíos comprende el establecimiento de un nuevo cuadro de envíos en el dispositivo de acceso programable.

10. El método de acuerdo con la reivindicación 1, en donde la transmisión de un mensaje de control comprende transmitir un mensaje de control para establecer una configuración de un programador y uno o más almacenamientos temporales de memoria de salida asociados en el dispositivo de acceso programable.

11. El método de acuerdo con la reivindicación 1, en donde la transmisión de un mensaje de control comprende transmitir un mensaje de control de configurador para establecer una configuración de un configurador en el dispositivo de acceso programable.

12. El método de acuerdo con la reivindicación 1, en donde; transmitir un mensaje de control desde el procesador externo al dispositivo de acceso programable para establecer una configuración del dispositivo de acceso programable comprende transmitir un mensaje de control especificando una fuente a partir de la cual los paquetes no son aceptados; y el método que además comprende dar de baja paquetes desde la fuente especificada a través del dispositivo de acceso programable.

13. El método de acuerdo con la reivindicación 1, y además comprendiendo en respuesta al procesamiento del servicio mediante el procesador externo, inyectar un paquete desde el procesador externo dentro del flujo de paquetes a través del dispositivo de acceso programable.

14. El método de acuerdo con la reivindicación 1, en donde: transmitir un mensaje de control desde el procesador externo al dispositivo de acceso programable para establecer una configuración del dispositivo de acceso programable comprende transmitir un mensaje de control de eliminación de sesión; y el método además comprende que el dispositivo de acceso programable elimine una sesión especificada mediante el mensaje de control de eliminación de sesión.

15. El método de acuerdo con la reivindicación 1, y además comprende la señalización del procesador externo, hardware de red para establecer una conexión de red en respuesta a la recepción de un mensaje desde el dispositivo de acceso programable.

16. El método de acuerdo con la reivindicación 1, y además comprende el intercambio de mensajes de mantener en vivo entre el procesador externo y el dispositivo de acceso programable.

17. El método de acuerdo con la reivindicación 1, en donde la transmisión de un mensaje de control comprende accesar un procesador de control en el procesador externo a través de una interfase de programación de aplicación.

18. El método de acuerdo con la reivindicación 1, y además comprende en respuesta a dicho mensaje de control, enviar una aceptación desde dicho dispositivo de acceso programable a dicho procesador externo.

19. El método de acuerdo con la reivindicación 1, y además comprende comunicar un estado de una sesión desde el dispositivo de acceso programable al procesador externo en respuesta a una falla de un controlador de servicio dando servicio a la sesión en el procesador externo.

20. El método de acuerdo con la reivindicación 1, en donde la transmisión de un mensaje de control comprende transmitir un mensaje de control a través de una red de comunicación intermedia.

21. Un sistema de acceso en red, comprendiendo: un procesador externo que transmite un mensaje de control especificando una configuración; y un dispositivo de acceso programable que, en respuesta al mensaje de control, establece la configuración especificada por el mensaje de control y comunica mensajes al procesador externo para procesamiento del servicio de acuerdo con la configuración.

22. El sistema de acceso en red, de acuerdo con la reivindicación 21, en donde: el dispositivo de acceso programable incluye un filtro de encabezado de paquete; el mensaje de control comprende un mensaje de control de filtro que establece una configuración del filtro de encabezado de paquete; y los mensajes comunicados a través del dispositivo de acceso programable comprenden mensajes de red filtrados desde un flujo de paquete a través del filtro de encabezado de paquete del dispositivo de acceso programable.

23. El sistema de acceso en red, de acuerdo con la reivindicación 22, dicho procesador comprendiendo medios para limitar la comunicación de mensajes de red desde el dispositivo de acceso programable a procesador externo, enviando al dispositivo de acceso programable un mensaje de configuración de banderas de interfase de mensaje en el dispositivo de acceso programable.

24. El sistema de acceso en red, de acuerdo con la reivindicación 21, en donde: el dispositivo de acceso programable comprende un monitor para el tráfico de la red; el mensaje de control comprende un mensaje de control de monitor que especifica una configuración del monitor; y los mensajes comunicados a través del dispositivo de acceso programable comprenden mensajes de reporte de acuerdo con la configuración ,

25. El sistema de acceso en red de acuerdo con la reivindicación 24, en donde el mensaje de control especifica un número de umbral de transmisiones permitidas.

26. El sistema de acceso en red de acuerdo con la reivindicación 24, en donde el mensaje de control de monitor especifica un nivel de actividad del umbral.

27. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde: el dispositivo de acceso programable comprende un vigilante; y el mensaje de control comprende un mensaje de control de vigilante que especifica una configuración del vigilante.

28. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde el mensaje de control comprende un mensaje de control del cuadro de envíos que especifica una configuración para el cuadro de envíos.

29. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde: el dispositivo de acceso programable comprende uno o más almacenes temporales de memoria de salida para paquetes salientes y un programador asociado; y el mensaje de control especifica una configuración para el programador y el uno o más almacenes de memoria temporales de salida.

30. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde: el dispositivo de acceso programable comprende un configurador; y el mensaje de control comprende un control de configurador que especifica una configuración del configurador.

31. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde: el mensaje de control especifica una fuente a partir de la cual los paquetes no serán aceptados; y el dispositivo de acceso programable comprende medios para dar de baja paquetes desde la fuente especificada.

32. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde dicho procesador externo comprende medios, en respuesta al procesamiento del servicio por el procesador externo, para inyectar un paquete dentro del flujo de paquetes a través del dispositivo de acceso programable.

33. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde: el mensaje de control comprende un mensaje de control de eliminación de sesión; y el dispositivo de acceso programable comprende medios para eliminar una sesión especificada por el mensaje de control de eliminación de sesión.

34. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde el procesador externo comprende un procesador de señalización que señala el hardware de red para establecer una conexión de red en respuesta a un mensaje recibido desde el dispositivo de acceso programable.

35. El sistema de acceso en red de acuerdo con la reivindicación 21, dicho procesador externo y dicho dispositivo de acceso programable cada uno comprendiendo medios para intercambiar mensajes de mantener en vivo.

36. El sistema de acceso en red de acuerdo con la reivindicación 21, en donde el procesador externo comprende un procesador de control que da salida a dicho mensaje de control y una interfase de programación de aplicación a través de la cual dicho procesador de control es accesado.

37. El sistema de acceso en red de acuerdo con la reivindicación 21 , en donde dicho dispositivo de acceso programabie comprende medios, en respuesta a dicho mensaje de control, para enviar una confirmación a dicho procesador externo.

38. El sistema de acceso en red de acuerdo con la reivindicación 21 , en donde: el procesador externo comprende una pluralidad de controladores de servicio que proporcionan procesamiento de servicio; y el dispositivo de acceso programabie comprende medios para comunicar un estado de una sesión al procesador externo en respuesta a una falla de un controlador de servicio dando servicio a la sesión.

39. El sistema de acceso en red de acuerdo con la reivindicación 21 , y además comprendiendo un acoplamiento de red al procesador externo y al dispositivo de acceso programabie.