Descripción General de la Señalización
Anuncio
Descripción General de la Señalización Descargue este capítulo Descripción General de la Señalización Descargue el libro completo Soluciones guía de configuración de la Calidad de servicio de Cisco IOS, versión 12.2SR (PDF - 6 MB) Feedback Contenidos Descripción General de la Señalización Precedencia IP Resource Reservation Protocol Cómo funciona Soporte de RSVP para el low latency queueing Restricciones Prerrequisitos Soporte de RSVP para el Frame Relay Asignación de ancho de banda de RSVP y interfaz de línea del comando modular qos (CLI) Beneficios Restricciones Prerrequisitos RSVP- Calidad de servicio de Interconexión de ATM Cómo funciona Un ejemplo de escenario POLIS para RSVP Cómo funciona Una mirada detallada en los POLIS para el funcionamiento de RSVP Subnetwork Bandwidth Manager Descripción General de la Señalización En el sentido más general, la señalización de QoS es una forma de comunicación de la red con la cual permite que una estación terminal o un nodo de red comunique, o de señal, sus vecinos de pedir la dirección especial de cierto tráfico. La señalización de QoS es útil para coordinar las técnicas de la gestión de tráfico proporcionadas por otras características de QoS. Desempeña una función fundamental en configurar el servicio de punta a punta total acertado de QoS a través de su red. QoS de punta a punta verdadero requiere que cada elemento en el trayecto de red — Switch, router, Firewall, host, cliente, y así sucesivamente — entregue su parte de QoS, y que todas estas entidades estén coordinadas con la señalización de QoS. Mucho QoS viable que señala las soluciones proporciona QoS en algunos lugares en la infraestructura; sin embargo, han limitado a menudo el alcance a través de la red. Para alcanzar QoS de punta a punta, señalando debe atravesar toda la red. El software de QoS del Cisco IOS se aprovecha del IP para hacer frente al desafío de encontrar un QoS robusto el señalar de la solución que puede actuar sobre las infraestructuras del heterogeneous network. Sobrepone la capa 2 QoS tecnologíaespecífico que señala las soluciones con los métodos de señalización de la capa 3 calidad del servicio de IP de las características del Resource Reservation Protocol (RSVP) y de la Prioridad IP. Una red del IP puede alcanzar QoS de punta a punta, por ejemplo, usando la parte de encabezado del paquete IP para pedir la dirección especial de la prioridad o del tráfico sensible al tiempo. Dado la ubicuidad del IP, la señalización de QoS que se aprovecha del IP proporciona la señalización de punta a punta potente. RSVP y la Prioridad IP cupieron esta categoría. La en-banda (Prioridad IP, 802.1p) o la señalización fuera de banda del (RSVP) se utiliza para indicar que un detalle QoS está deseado para una clasificación del tráfico determinado. La Prioridad IP señala para QoS distinguido, y RSVP para QoS garantizado. Precedencia IP Tal y como se muestra en del cuadro 1, la característica de la Prioridad IP utiliza los tres bits de precedencia en el campo de Tipo de servicio (ToS) versión IP de la encabezado 4 (del IPv4) para especificar la clase del servicio para cada paquete. Usted puede dividir el tráfico en hasta seis clases del servicio usando la Prioridad IP. Las Tecnologías de espera en la red pueden entonces utilizar esta señal de proporcionar la dirección apresurada apropiada. Cuadro 1 campo TOS de la Prioridad IP Usted puede utilizar las características tales como Routing basado en políticas (PBR) y Committed Access Rate (CAR) para fijar la precedencia basada en la clasificación de la lista de acceso ampliada. El uso de estas características permite la considerable flexibilidad de la asignación de la precedencia, incluyendo la asignación de la aplicación o del usuario, o por el destino o la subred de origen. Típicamente, usted despliega estas características tan cerca al borde de la red o del dominio administrativo como sea posible, de modo que cada elemento de redes subsiguiente pueda proporcionar el servicio basado en la directiva determinada. La Prioridad IP se puede también fijar en el host o el cliente de red; sin embargo, la Prioridad IP se puede reemplazar por la directiva dentro de la red. La Prioridad IP habilita las clases de servicio que se establecerán usando los mecanismos de espera de la red existente, tales como espera cargada de la feria (WFQ) y Weighted Random Early Detection (WRED), sin los cambios a las aplicaciones existentes y sin los requisitos de la red complicada. Resource Reservation Protocol RSVP es el primer protocolo significativo del estándar de la industria para dinámicamente configurar QoS de punta a punta a través de un heterogeneous network. RSVP, que ejecuta encima el IP, permite que una aplicación reserve dinámicamente el ancho de banda de la red. Usando RSVP, las aplicaciones pueden pedir cierto nivel de QoS para un flujo de datos a través de una red. La implementación de Calidad de servicio(QoS) del Cisco IOS permite que RSVP sea iniciado dentro de la red usando el proxy configurado RSVP. Usando esta capacidad, usted puede aprovecharse de las ventajas de RSVP en la red incluso para NONRSVP habilitó las aplicaciones y los hosts. RSVP es el único protocolo de señalización estándar diseñado para garantizar el ancho de banda de la red de punta a punta para las redes IP. RSVP no realiza su propia encaminamiento; en lugar utiliza los Routing Protocol subyacentes para determinar donde debe llevar las solicitudes de reserva. Como trayectorias de los cambios de ruteo a adaptarse a los cambios de la topología, RSVP adapta su reserva a las nuevas trayectorias dondequiera que las reservas existan. Esta modularidad no evita que RSVP utilice otros servicios de ruteo. RSVP proporciona la operación segura a través de los nodos del router que no soportan RSVP. RSVP trabaja conjuntamente con, no en lugar de, los mecanismos de espera actuales. El RSVP pide el QoS determinado, pero está hasta el mecanismo de espera de la interfaz particular, tal como WFQ o WRED, implementar la reserva. Usted puede utilizar RSVP para hacer dos tipos de las reservas dinámicas: servicios controlados de la carga y de la tarifa garantizada, que se describen abreviadamente en el capítulo “descripción de la calidad de servicio” en este libro. Una característica primaria de RSVP es su scalability. Escalas de RSVP bien usando el scalability inherente del Multicast. Escalas de RSVP a los grupos de multidifusión muy grandes porque utiliza las solicitudes de reserva receptor-orientadas que se combinan mientras que progresan encima del árbol de multidifusión. Aunque RSVP se diseñe específicamente para las aplicaciones de multidifusión, puede también hacer las reservas del unicast. Sin embargo, no escala también con un gran número de reservas del unicast. RSVP es un importante función de calidad de servicio (QoS), pero no soluciona todos los problemas abordados por QoS, e impone algunos obstáculos, tales como el tiempo requerido para configurar la reserva de punta a punta. Cómo funciona Uso RSVP de los hosts y del Routers de entregar las peticiones de QoS al Routers a lo largo de las trayectorias de la secuencia de datos y de mantener el estado del router y de host para proporcionar el servicio pedido, generalmente ancho de banda y tiempo de espera. El RSVP utiliza una velocidad de datos mala — la cantidad más grande de datos que el router mantendrá la cola — y QoS mínimo (es decir, garantía del ancho de banda pedido especificado cuando usted hizo la reserva usando el RSVP) para determinar la reserva de ancho de banda. Un host utiliza RSVP para pedir un servicio específico de QoS de la red en nombre de una secuencia de los datos de aplicación. El RSVP pide el QoS determinado, pero está hasta el mecanismo de espera de la interfaz para implementar la reserva. RSVP lleva la petición a través de la red, visitando cada nodo los usos de la red de llevar la secuencia. En cada nodo, el RSVP intenta hacer una reserva de recursos para la secuencia usando su propio módulo de control de admisión, exclusiva al RSVP, que determina si el nodo tiene los suficientes recursos disponibles para suministrar el QoS pedido. Observepara RSVP, una aplicación podría enviar el tráfico a una tarifa más arriba que el QoS pedido, pero la aplicación se garantiza solamente la velocidad solicitada mínima. Si el ancho de banda está disponible, el tráfico que supera la velocidad solicitada irá a través si está enviado; si el ancho de banda no está disponible, el tráfico excedente será caído. Si los recursos requeridos están disponibles y conceden el usuario el acceso administrativo, la daemon de RSVP fija los argumentos en el planificador de trabajos del clasificador de paquetes y del paquete para obtener el QoS deseado. El clasificador determina la clase de QoS para que cada paquete y la transmisión de paquetes de las órdenes del planificador de trabajos alcancen el QoS prometido para cada secuencia. Si o el recurso es inasequible o niegan el usuario el permiso administrativo, el programa de RSVP devuelve una notificación de error al proceso de la aplicación que originó la petición. El WFQ o el WRED configura la clasificación de paquetes y la previsión requeridas para los flujos reservados. Usando el WFQ, RSVP puede entregar un servicio de la tarifa garantizada de los Servicios integrados. Usando el WRED, puede entregar una carga de servicio controlada. Para la información sobre cómo configurar RSVP, vea el capítulo el “configurar de RSVP” en este libro. Soporte de RSVP para el low latency queueing RSVP es un protocolo network-control que proporciona los medios para reservar a los recursos de red — sobre todo ancho de banda — para garantizar que el envío de las aplicaciones de punta a punta a través de las redes alcanza el QoS deseado. RSVP permite al tráfico en tiempo real (que incluye los flujos de la voz) para reservar los recursos necesarios para la latencia baja y las garantías de ancho de banda. El tráfico de voz tiene requisitos rigurosos de la fluctuación y retraso. Debe tener el retardo muy bajo y jitter mínimo por el salto para evitar la degradación de QoS de punta a punta. Este requisito pide una implementación de envío a cola eficiente, tal como low latency queueing (LLQ), que puede casi mantener el tráfico de voz en la prioridad estricta para minimizar la fluctuación y retraso. RSVP utiliza el WFQ para proporcionar la imparcialidad entre los flujos y para asignar una ponderación baja a un paquete para lograr la prioridad. Sin embargo, el trato preferencial proporcionado por RSVP es escaso para minimizar el jitter debido a la naturaleza del algoritmo de envío a cola sí mismo. Como consecuencia, la latencia baja y los requisitos del jitter de los flujos de la voz no se pudieron cumplir en la implementación anterior de RSVP y del WFQ. RSVP proporciona el control de admisión. Sin embargo, para proporcionar el ancho de banda y para retrasar las garantías para el tráfico de voz y para conseguir el control de admisión, RSVP debe trabajar con el LLQ. El soporte de RSVP para la característica LLQ permite que RSVP clasifique los flujos de la voz y que los haga cola en el priority queue dentro del sistema LLQ mientras que simultáneamente proporciona a las reservas para los flujos nonvoice consiguiendo una Cola reservada. El cuadro 2 muestra tales como cómo RSVP actúa con otras características de la voz sobre IP (VoIP) ip rtp priority, usando el mismo mecanismo de espera, LLQ. Cuadro 2 soporte de RSVP para el LLQ RSVP es el único protocolo que proporciona el control de admisión basado en la Disponibilidad de los recursos de red tales como ancho de banda. El LLQ proporciona los medios de remitir el tráfico de voz con la prioridad estricta delante del otro tráfico de datos. Cuando está combinado, el soporte de RSVP para el LLQ proporciona el control de admisión y adelante los flujos de la voz con el tiempo de espera y el jitter posibles más bajos. El tráfico nonvoice prioritario de las aplicaciones esenciales para la misión puede continuar siendo enviado sin al contrario ser afectado por el tráfico de voz. El tráfico de Nonconformant recibe el tratamiento del mejor esfuerzo, de tal modo evitando cualquier degradación que pudiera ocurrir de otra manera para todo el tráfico. El soporte de RSVP para los soportes de característica LLQ los RFC siguientes: • RFC 2205, Resource Reservation Protocol • RFC 2210, RSVP con los Servicios integrados IETF • RFC 2211, servicio del elemento de redes de la Controlado-carga • RFC 2212, especificación de la calidad de servicio garantizada • RFC 2215, Parámetros generales de caracterización para los elementos de redes del servicio integrado El cuadro 3 muestra una topología de red de muestra con el LLQ que se ejecuta en cada interfaz. Esta configuración garantiza QoS para el tráfico de voz. Observesi la fuente es incapaz de soportar RSVP, después el router puede proxy en nombre de la fuente. Cuadro 3 topología que muestra el LLQ en cada interfaz Para la información sobre cómo configurar el soporte de RSVP para la característica LLQ, vea “configurando el soporte de RSVP para el módulo LLQ”. Restricciones Las restricciones siguientes aplican a RSVP el soporte para la característica LLQ: • El LLQ no se soporta en ninguna túneles. • El soporte de RSVP para el LLQ es dependiente en el priority queue. Si el LLQ no está disponible en ninguna interfaz o plataforma, después el soporte de RSVP para el LLQ no está disponible. Prerrequisitos La red debe soportar las características deL Cisco IOS siguientes antes de que el soporte de RSVP para el LLQ se habilite: • RSVP • WFQ o LLQ (WFQ con el soporte del priority queue) Soporte de RSVP para el Frame Relay Los administradores de la red utilizan la espera para manejar la congestión en una interfaz del router o un virtual circuit (VC). En un entorno de Frame Relay, el punto de congestión no pudo ser la interfaz sí mismo, sino el VC debido a la Velocidad de información comprometida (CIR). Para el tráfico en tiempo real (flujos de la voz) que se enviará a tiempo, la velocidad de datos no debe exceder el CIR o los paquetes se pudo caer, de tal modo afectando a la Calidad de voz. El Control de tráfico de Frame Relay (FRTS) es configurado en las interfaces para controlar la tarifa del tráfico saliente evitando que el router exceda el CIR. Los este tipos de configuración significan esa suposición que hace cola por ejemplo el Class-Based WFQ (CBWFQ), LLQ, o el WFQ, puede ejecutarse en el VC para proporcionar las garantías de QoS para el tráfico. Previamente, los Reservación RSVP no fueron obligados por el CIR del VC saliente del flujo. Como consecuencia, el oversubscription podría ocurrir cuando la suma del tráfico de RSVP y del otro tráfico excedió el CIR. El soporte de RSVP para la característica de Frame Relay permite que RSVP funcione con por VC (identificador de conexión de link de datos (DLCI) que hace cola para Voz-como los flujos. El modelado de tráfico se debe habilitar en un entorno de Frame Relay para el control de admisión exacto de los recursos (ancho de banda y las colas de administración del tráfico) en el punto de congestión, es decir, el VC sí mismo. Específicamente, RSVP puede funcionar con VCs definió en los niveles de interfaz y subinterfaz. No hay límite al número de VCs que se puede configurar por la interfaz o la subinterfaz. Asignación de ancho de banda de RSVP y interfaz de línea del comando modular qos (CLI) RSVP puede utilizar un algoritmo de envío a cola de la interfaz (o un PVC), tal como WFQ, para asegurar QoS para sus flujos de datos. Control de admisión Cuando el WFQ se está ejecutando, RSVP puede coexistir con otras características de QoS en una interfaz (o el PVC) ese también ancho de banda de la reserva y aplicar QoS. Cuando usted configura las características de ancho de banda-reserva del múltiplo (tales como RSVP, LLQ, CB-WFQ, y ip rtp priority), las porciones del ancho de banda disponible de la interfaz (o los PVC) se pueden asignar a cada uno de estas características para el uso con los flujos que clasifican. Un administrador de ancho de banda basado en la interfaz (o de PVC) interno evita que la cantidad de tráfico reservada por estas características oversubscribing la interfaz (o el PVC). Usted puede ver este pool del ancho de banda disponible usando show queue el comando. Cuando usted configura las características tales como LLQ y CB-WFQ, cualesquiera clases que se asignen a reserva del ancho de banda su ancho de banda a la hora de la configuración, y deducen este ancho de banda del administrador de ancho de banda. Si el configuré el ancho de banda excede la capacidad de la interfaz, se rechaza la configuración. Cuando se configura RSVP, no hay ancho de banda reservado. (La cantidad de ancho de banda especificada en ip rsvp bandwidth el comando actúa como límite superior estricto, y not garantiza la admisión de cualquier flujo.) Solamente cuando llega un Reservación RSVP hace la tentativa de RSVP de reservar el pool restante de los del ancho de banda del ancho de banda disponible (es decir, el ancho de banda que no ha sido dedicado para traficar dirigido por las otras funciones.) Clasificación del paquete de datos Por abandono, RSVP realiza un flujo basado eficiente, clasificación del datapacket para asegurar QoS para su tráfico reservado. Esta clasificación se ejecuta antes de la consideración de espera por ip rtp priority o de CB-WFQ. Así, el uso de una clase o de un comando ip rtp priority CB-WFQ not se requiere para que los flujos de datos de RSVP sean concedidos QoS. La configuración ip rtp priority ningunos o CB-WFQ no hará juego los flujos de RSVP, sino que reservarán el ancho de banda adicional para cualquier flujo de NON-RSVP que pueda hacer juego sus clasificadores. Beneficios Las ventajas de esta característica incluyen el siguiente: • RSVP ahora proporciona el control de admisión basado en el valor saliente aceptable mínimo del VC (mincir), si está definido, en vez de la cantidad de ancho de banda disponible en la interfaz. • RSVP proporciona las garantías de QoS para el tráfico de prioridad alta reservando los recursos actualmente la congestión, es decir, el VC de Frame Relay en vez de la interfaz. • RSVP proporciona el soporte para las configuraciones de la interfaz Point-to-Point y Multipoint, así habilitando el despliegue de los servicios tales como VoIP en los entornos de Frame Relay con las garantías de QoS. • RSVP, el CBWFQ, y ip rtp priority el comando no hacen oversubscribe la cantidad de ancho de banda disponible en la interfaz o el VC incluso cuando se están ejecutando simultáneamente. Antes de admitir una reserva, estas características (y ip rtp priority el comando) consultan con un administrador de ancho de banda interno para evitar el oversubscription. • Calidad del servicio de IP las características pueden ahora ser seamlessly integrado del IP en los entornos de Frame Relay con RSVP que proporciona al control de admisión en una base por VC (DLCI). El soporte de RSVP para la característica de Frame Relay soporta el MIB y los RFC siguientes: • RFC 2206, Management Information Base de RSVP usando SMIv2 • RFC 220, Resource Reservation Protocol • RFC 2210, RSVP con los Servicios integrados IETF • RFC 221, servicio del elemento de redes de la Controlado-carga • RFC 2212, especificación de la calidad de servicio garantizada • RFC 2215, Parámetros generales de caracterización para los elementos de redes del servicio integrado Para la información sobre cómo configurar el soporte RVSP para el Frame Relay, vea “configurando el soporte de RSVP para el módulo del Frame Relay”. Restricciones Las restricciones siguientes aplican a RSVP el soporte para la característica de Frame Relay: • el Control de tráfico genérico (GTS) del Interfaz-nivel no se soporta. • la espera y la colocación en cola en el nivel de la interfaz del VC-nivel en la misma interfaz no se soportan. • Los flujos Nonvoice de RSVP no se soportan. • Los flujos del Multicast no se soportan. Prerrequisitos La red debe soportar las características deL Cisco IOS siguientes antes de que el soporte de RSVP para el Frame Relay se habilite: • RSVP • WFQ en el VC • LLQ • Foro de Frame Relay (FRF).12 en la interfaz RSVP- Calidad de servicio de Interconexión de ATM La función de interfuncionamiento RSVP-ATM QoS proporciona el soporte para la carga de servicio controlada usando RSVP sobre una red del núcleo atmósfera. Esta característica requiere la capacidad de señalar para el establecimiento de los circuitos virtuales conmutados (SVC) a través de la nube ATM en respuesta a los mensajes request del Reservación RSVP. Para cumplir este requisito, el RSVP over ATM soporta la asignación de las sesiones RSVP a la atmósfera SVC. La función de interfuncionamiento RSVP-ATM QoS permite que usted realice las tareas siguientes: • Configure una interfaz o una subinterfaz para crear dinámicamente los SVC en respuesta a los mensajes request del Reservación RSVP. Para asegurar definió QoS, estos SVC se establecen teniendo perfiles de QoS constantes con las especificaciones asociadas del flujo de RSVP (flowspecs). • Asocie las definiciones distribuidas del grupo del Weighted Random Early Detection (DWRED) a la interfaz del adaptador de puerto ATM mejorado (PA-A3) para soportar la política para tirar paquetes por VC DWRED. El uso del DWRED por VC se asegura de que si los paquetes deben ser caídos, después los paquetes del mejor esfuerzo se caen primero y no los que se ajusten al QoS apropiado determinado por el token bucket de RSVP. • Configure los valores de la Prioridad IP y TOS que se utilizarán para los paquetes que se ajustan a o exceden los perfiles de QoS. Como parte de su proceso de entrada, RSVP utiliza los valores que usted especifica para fijar los bits TOS y de la Prioridad IP en los paquetes entrantes. Si se configura el DWRED por VC, entonces utiliza las configuraciones TOS y del bit de precedencia IP en la interfaz de salida del mismo router en determinar que los paquetes a caer. También, las interfaces en los routeres en sentido descendente utilizan estas configuraciones en el proceso de los paquetes. Esta característica se soporta en los Cisco 7500 Series Router con un VIP2-50 y un adaptador de puerto ATM mejorado (PAA3). El hardware proporciona el modelado de tráfico requerido por la característica y satisface el requisito de rendimiento del índice de OC-3. Cómo funciona Tradicionalmente, RSVP se ha juntado con el WFQ. El WFQ proporciona las garantías de ancho de banda a RSVP y da la visibilidad de RSVP a todos los paquetes visibles a él. Esta visibilidad permite que RSVP identifique y que marque los paquetes en relación con ella. La función de interfuncionamiento RSVP-ATM QoS permite que usted desempareje RSVP del WFQ, y en lugar de otro lo asocia a la atmósfera SVC para dirigir los mensajes de la solicitud de reserva (y proporcionar las garantías de ancho de banda) y el Netflow para hacer los paquetes visibles a RSVP. Para configurar una interfaz o una subinterfaz para utilizar la función de interfuncionamiento RSVP-ATM QoS, utilice ip rsvp svc-required el comando. Entonces, siempre que se pida un nuevo Reservación RSVP, el software del router establece una nueva atmósfera SVC para mantener la reserva. Para asegurar la correspondencia entre los valores de RSVP y atmósfera SVC, el software algorítmico asocia la tarifa y los parámetros de tamaño de ráfaga en el flowspec de RSVP a la velocidad continua de celda atmósfera (SCR) y a los tamaños máximos de ráfaga (MBS). Para la velocidad de célula de cresta (PCR), utiliza el valor que usted configura u omite la línea tarifa. El RSVP-ATM QoS que intertrabaja requiere un adaptador de puerto ATM mejorado (PA-A3) con la velocidad OC-3. Cuando un paquete que pertenece a un flujo reservado llega en la interfaz o la subinterfaz, el software que intertrabaja RSVPATM QoS utiliza un token bucket para manejar las garantías de ancho de banda. Mide las relaciones del tráfico reales contra el flowspec de la reserva para determinar si el paquete se ajusta a o excede el flowspec. Usando le valora configuración para conformant o el tráfico excedente, fija los bits de la Prioridad IP y TOS en el Byte ToS de la encabezado del paquete y entrega el paquete al virtual circuit (VC) apropiado para la transmisión. Para la función de interfuncionamiento RSVP-ATM QoS, se forman los paquetes antes de que se envíen en la atmósfera SVC. El shaping crea la presión posterior al Versatile Interface Processor (VIP) cuando la carga ofrecida excede la tarifa. El software que intertrabaja RSVP-ATM QoS utiliza por-SVC DWRED para caer los paquetes cuando el formar hace una cola acumularse en el VIP. El uso de por-SVC DWRED permite que RSVP entregue la clase de la carga de servicio controlada, que requiere que los paquetes reservados experimenten el funcionamiento equivalente al de una red descargada (que sea una con el retardo muy de pequeñas pérdidas y moderado). Para una más cuenta detallada de cómo los trabajos de la función de interfuncionamiento RSVP-ATM QoS, consideran el escenario del siguiente ejemplo. Un ejemplo de escenario Para entender el comportamiento de la función de interfuncionamiento RSVP-ATM QoS, considere el siguiente ejemplo, que utiliza a un Cisco 7500 Router con el ingreso VIP y las interfaces de egreso y las funciones del ingreso RSVP implementadas en el Route Switch Processor (RSP). El cuadro 4 ilustra este ejemplo; muestra a un par de Routers que comunique sobre la nube ATM. En este ejemplo, un solo PVC se utiliza para los mensajes request de RSVP y una atmósfera SVC se establece para manejar cada nuevo mensaje de la solicitud de reserva. Cuadro 4 dos Routers conectado sobre una red del núcleo atmósfera Reciba X, que está por aguas arriba del router A, está conectado directamente con el router A usando el FDDI. Reciba Y, que es rio abajo del router B, está conectado directamente con el router B usando el FDDI. (En una configuración alternativa, estas conexiones del router del host podrían utilizar la atmósfera VCs.) Para la función de interfuncionamiento RSVP-ATM QoS, las reservas se necesitan sobre todo entre el Routers a través de la red de estructura básica de ATM. Para limitar el número de ubicaciones en donde se hacen las reservas, usted puede habilitar RSVP selectivamente solamente en las subinterfaces correspondiente a las conexiones del router a router a través de la red de estructura básica de ATM. Evitando que las reservas sean hechas entre el host y el router el uso del VC de ambos límites y reduce la carga en el router. Los mensajes RSVP RESV fluyen de recibir el host a enviar el host. En este ejemplo, el host Y es el host de envío y el host X es el host de recepción. (El host Y envía un mensaje RESV para recibir el X.) el router B, que está en el borde de la nube ATM, recibe el mensaje RESV y adelante lo por aguas arriba al router A a través del PVC usado para los mensajes del control. El ejemplo de configuración mostrado en el cuadro 4 utiliza un PVC; como se muestra, lleva la petición de RSVP. La interfaz de ingreso en el router A se configura para el RSVP-ATM, que le permite para establecer para cada petición SVC de mantener cualquier nueva reserva de RSVP RESV hizo en la interfaz. Cuando recibe una solicitud de reserva, la interfaz en el router A crea una nueva Velocidad de bits variable no en tiempo real (nRTVBR) SVC con las características QoS apropiadas. Las características QoS usadas para establecer el resultado de SVC de la asignación algorítmica del flowspec en el mensaje RSVP RESV al conjunto apropiado de los parámetros de señalización atmósfera. En este ejemplo, utilizan a la carga de servicio controlada como la clase de QoS. El parámetro PCR atmósfera se fija a la línea tarifa. Si ip rsvp atm-peak-rate-limit el comando se utiliza en la interfaz de configurar un limitador de la tarifa, el PCR se fija al limitador de la velocidad pico. El parámetro SCR atmósfera se fija a la tarifa del flowspec de RSVP y la atmósfera MBS se fija a los tamaños de ráfaga del flowspec de RSVP. Se forman los paquetes antes de que se envíen en la atmósfera SVC. El shaping crea la presión posterior al VIP cuando la carga ofrecida excede la tarifa. Cuando un nuevo SVC se configura para manejar una solicitud de reserva, otro estado también se configura incluyendo un estado del clasificador que utilice las direcciones de origen y de destino y los números del puerto del paquete para determinar al cual, eventualmente, la reserva el paquete pertenece. También, un token bucket se configura para asegurarse de que si una fuente envía más datos que la velocidad de datos y los parámetros MBS de su flowspec especifican, el tráfico en exceso no interfiere con otras reservas. La sección siguiente describe más concretamente, cómo los datos atraviesan la trayectoria. Cuando un paquete de datos destinado para el router B llega el router A, antes de que atraviesen la nube ATM, marcan a las direcciones de origen y de destino y los números del puerto del paquete contra filtro RSVP la especificación (filterspec) para determinar si el paquete corresponde con una reserva. Si el paquete no hace juego una reserva, se envía el mejor esfuerzo PVC al router B. Si un paquete hace juego una reserva, es procesado más a fondo por RSVP. El paquete se marca contra el token bucket de la reserva para determinar si se ajusta a o excede los parámetros del token bucket. (Todos los paquetes que corresponden con una reserva se envían en SVC de la reserva para prevenir misordering de los paquetes.) Para introducir la diferenciación entre los paquetes flowspec-conformant y flowspec-excedentes, usted puede especificar los valores para que el RSVP-ATM utilice en la determinación de los bits de la Prioridad IP y TOS de los paquetes. Para especificar estos valores, usted utiliza ip rsvp precedence y ip rsvp tos los comandos. Cuando usted fija diversos valores de precedencia para los paquetes conformant y excedentes y utiliza una política para tirar paquetes preferencial tal como DWRED, el RSVPATM se asegura que eso flowspec-que se excede los paquetes estén caídos antes de los paquetes flowspec-conformant cuando se congestiona el VC. Para la información sobre cómo configurar la función de interfuncionamiento RSVP-ATM QoS, vea “configurar el módulo que intertrabaja RSVP-ATM QoS”. POLIS para RSVP El Servicio de políticas abiertas comunes (COPS) es un protocolo para la información de política de comunicación del tráfico de la red a los dispositivos de red. RSVP es los medios para reservar a los recursos de red — sobre todo ancho de banda — para garantizar que el envío de las aplicaciones de punta a punta a través de Internet se realizará en la velocidad deseada y la calidad. Combinados, los POLIS con RSVP dan el monitoreo y control centralizado los administradores de la red de RSVP, incluyendo las capacidades siguientes: • Asegure el ancho de banda adecuado y esté inquieto y retrase los límites para el tráfico sensible al tiempo tal como transmisión de voz • Asegure el ancho de banda adecuado para las aplicaciones multimedia tales como videoconferencia y Aprendizaje a distancia • Evite que las aplicaciones ancho de banda-hambrientas el retraso de los flujos de la prioridad máxima o dañen el funcionamiento de otras aplicaciones ejecutadas acostumbradamente sobre la misma red Al obrar así, los POLIS para RSVP soportan las características cruciales siguientes de RSVP: • Control de admisión. Se valida o se rechaza el Reservación RSVP basado en los recursos de red disponibles de punta a punta. • Garantía de ancho de banda. El Reservación RSVP, si está validado, garantizará que esos recursos reservados continuarán estando disponibles mientras que la reserva existe. • Reserva independiente de medios. Un Reservación RSVP de punta a punta puede atravesar los tipos de media arbitrarios de la capa inferior. • Clasificación de los datos. Mientras que una reserva existe, los paquetes de datos que pertenecen a ese flujo de RSVP se separan de otros paquetes y se remiten como parte del flujo reservado. • Policing de los datos. Los paquetes de datos que pertenecen a RSVP fluyen que exceden los tamaños del ancho de banda reservado se marcan con una precedencia del paquete más baja. Observepara utilizar los POLIS para la característica de RSVP, su red debe ser Cisco IOS 12.1(1)T corriente o versiones posteriores. Por otra parte, un servidor de políticas compatible se debe conectar con la red, tal como Cisco CAPTURA el QoS Policy Manager. Observela versión del Cisco IOS 12.1(2)T de los POLIS para RSVP no soporta RSVP+. Los POLIS para RSVP funcionan en las interfaces siguientes: • Ethernet • Fast ethernet • Interfaz en serie de alta velocidad (HSSI): V.35, EIA/TIA-232 • C1 Los POLIS para los soportes de característica de RSVP los RFC siguientes: • RFC 2749, uso de los POLIS para RSVP • RFC 2205, Resource Reservation Protocol (RSVP) • RFC 2748, el protocolo de los POLIS (Servicio de políticas abiertas comunes) Cómo funciona Esta sección proporciona una descripción general de alto nivel de cómo los POLIS para la característica de RSVP trabajan en su red, y proporciona los pasos generales para configurar los POLIS para la característica de RSVP. El cuadro 5 es un arreglo de la muestra de los POLIS con RSVP. Cuadro 5 arreglo de la muestra de POLIS con RSVP Para configurar a un router para procesar todos los mensajes RSVP que vienen a él según las directivas salvadas en un servidor de políticas determinado (llamado el punto de decisión de políticas, o PDP), realice los pasos siguientes: 1. En el servidor PDP ingrese las directivas usando el QoS Policy Manager de los POLIS de Cisco o una aplicación de administrador compatible de la directiva. 2. Configure al router (a través de su interfaz de la línea de comandos) para pedir las decisiones del servidor con respecto a los mensajes RSVP. Después que la configuración, los flujos de red es procesada por el router señalado como la punta de la aplicación de políticas (PEP), como sigue: a. Cuando RSVP que señala el mensaje llega el router, el router pregunta a servidor PDP cómo procesar el mensaje, para validar, rechazar, remite, o instala el mensaje. b. El servidor PDP envía su decisión al router, que entonces procesa el mensaje según lo dado instrucciones. 3. Alternativamente, usted puede configurar al router para tomar esas decisiones sí mismo (“localmente”) sin él que necesita consultar primero con el servidor PDP. (La característica local no se soporta en esta versión sino estará en una futura versión.) Una mirada detallada en los POLIS para el funcionamiento de RSVP El cuadro 6 opciones de las trazas disponibles en Administración de políticas del mensaje RSVP fluye. Para cada opción, un ejemplo del comando router configuration usado para fijar que la opción está dada en los corchetes y el tipo negrita. La área sombreada cubre las operaciones de la política local; el resto de la figura ilustra la operación remota de la directiva. (Configurar la política local estará disponible en una futura versión.) Cuadro 6 pasos en el proceso de la TRAYECTORIA y de los mensajes RESV de RSVP La siguiente información se cierra a la figura: a. El router recibe una TRAYECTORIA o el mensaje RESV y el primer intenta juzgarla localmente (es decir, sin referir al servidor de políticas). Si han configurado al router para juzgar el Listas de control de acceso (ACL) específico localmente y el mensaje hace juego una de esas listas (a-1), el módulo de la directiva del router aplica a los operadores con quienes había sido configurado. Si no, el proceso de la directiva continúa (a-2). b. Para cada mensaje rechazado por los operadores, el router envía un mensaje de error al remitente y quita la TRAYECTORIA o el mensaje RESV de la base de datos (b-1). Si el mensaje no se rechaza, el proceso de la directiva continúa (b-2). c. Si el indicador local de la invalidación se fija para esta entrada, el mensaje se valida inmediatamente con los operadores especificados de la directiva (c-1). Si no, el proceso de la directiva continúa (c-2). d. Si el mensaje no hace juego ningún ACL configurado para la política local (a-2), el router aplica la política local predeterminada (d-1). Sin embargo, si no se ha configurado ninguna política local predeterminada, el mensaje se dirige hacia el proceso remoto de la directiva (d-2). e. Si han configurado al router con los ACL específicos contra los servidores de políticas específicos (PDPs), y las coincidencias una del mensaje de estos ACL, el router envía ese mensaje al PDP específico para el juicio (e-1). Si no, el proceso de la directiva continúa (e-2). f. Si el PDP especifica una decisión del “rechazo” (f-1), se desecha el mensaje y un mensaje de error se devuelve al remitente, indicando esta condición. Si el PDP especifica “valide” la decisión (F2), el mensaje se valida y se procesa usando RSVP normal que procesa las reglas. g. Si el mensaje no hace juego ningún ACL configurado para PDPs específico (e-2), el router aplica la configuración del valor por defecto PDP. Si un valor por defecto CAPTURA se ha ingresado la configuración, proceso de la directiva continúa (g-1). Si no, el mensaje se considera ser incomparable (g-2). Si la decisión de política predeterminada para los mensajes incomparables es rechazar (h-1), el mensaje se desecha inmediatamente y un mensaje de error se envía al remitente que indica esta condición. Si no, el mensaje se valida y se procesa usando RSVP normal que procesa las reglas (h-2). Aquí están los detalles adicionales sobre la comunicación y el proceso PDP-PEP: • Temporizador de la petición de la directiva. Siempre que un pedido el juicio (de cualquier clase) se envíe a un PDP, un temporizador 30-second se asoció a la TRAYECTORIA o se comienza el mensaje RESV. Si el temporizador se ejecuta hacia fuera antes de que el PDP conteste a la petición, el PDP se asume para estar abajo y la petición se da a la política predeterminada (paso g-2 en el cuadro 6). • Seguimiento PDP de las reservas PEP. Cuando el PDP especifica que una reserva puede ser instalada, esta reserva se debe entonces instalar en el router. Una vez que se ha afectado un aparato la capacidad de ancho de banda y la reserva ha estado instalada, el módulo de la directiva del PEP envía un mensaje del COMETER al PDP. Pero si la reserva no se podría instalar debido a los recursos insuficientes, la reserva plegable de nuevo al estado noninstalled y un mensaje NO-COMMIT se envía al PDP. Si la reserva era también nueva (ningún estado anterior), después un mensaje request de la CANCELACIÓN en lugar de otro se envía al PDP. De estas maneras, el PDP puede no perder de vista las reservas en el PEP. • Resincronización. Si el PDP envía un mensaje SYNCHRONIZE-REQUEST al PEP, el módulo de la directiva del PEP analiza su base de datos para todas las trayectorias y reservas que fueron juzgadas previamente por este PDP, y vuelve a enviar las peticiones para ellas. Se conserva la información de política previamente juzgada hasta que se reciba una nueva decisión. Cuando todos los estados de la TRAYECTORIA o RESV han estado señalados al PDP, un mensaje SYNCHRONIZE-COMPLETE es enviado por el módulo de la directiva al PDP. El PEP también envía las interrogaciones referentes a todos los flujos que localmente fueron juzgados mientras que el PDP estaba abajo. • Readjudication: – Siempre y cuando los flujos gobernados por la sesión RSVP continúan pasando a través del router PEP, el PDP puede decidir unilateral a las decisiones unas de los de los POLIS del readjudicate de esa sesión. Por ejemplo, el PDP pudo decidir a que un flujo determinado que ahora fue concedido anterior las necesidades de la aceptación de ser rechazado (deuda quizás a un derecho preferente de compra o a un descanso súbito). En estos casos, el PDP envía un nuevo mensaje de la decisión al PEP, que entonces ajusta su comportamiento por consiguiente. – Si el router PEP recibe un mensaje RESV en el cual un objeto ha cambiado, la decisión de políticas necesita readjudicated. Por ejemplo, si el remitente quiere aumentar o disminuir la reserva de ancho de banda, una nueva decisión de políticas debe ser tomada. En estos casos, los indicadores de la directiva aplicados previamente a esta sesión se conservan, y la sesión readjudicated. • Desmontajes. El módulo de la directiva del PEP es responsable de notificar el PDP siempre que una reserva o una trayectoria que fueron establecidas previamente con la directiva se derribe por cualquier motivo. El PEP notifica el PDP enviando el PDP un mensaje request de la CANCELACIÓN. • Administración de la conexión: – Si la conexión al PDP es cerrada (cualquiera porque el PDP cerró la conexión, un error TCP/IP ocurrió, o el Keepalives fallado), el PEP publica un mensaje CLIENT-CLOSE y después intenta volver a conectar al mismo PDP. Si el PEP recibe un mensaje CLIENT-CLOSE que contiene un PDP reorienta el direccionamiento, el PEP intenta conectar con el PDP reorientado. – Si cualquier tentativa falla, el PEP intenta conectar con el PDPs especificado previamente en el comando configuration ip rsvp policy cops servers , obedeciendo la secuencia de servidores dados en ese comando, comenzando siempre con el primer servidor en esa lista. – Si el PEP alcanza el extremo de la lista de servidores sin la conexión, espera cierto rato (llamado “vuelva a conectar el retardo”) antes de intentar otra vez conectar con el primer servidor en la lista. Esto vuelve a conectar el retardo es inicialmente 30 segundos, y dobles cada vez que el PEP alcanza el extremo de la lista sin la conexión, hasta que el retardo del volver a conectar se convierta en su máximo de 30 minutos. Tan pronto como se haga una conexión, el retardo se reajusta a 30 segundos. • Objetos del reemplazo — La matriz en el cuadro 1 identifica los objetos que el PDP puede substituir dentro de los mensajes RSVP que pasan con el PEP. Un x en la columna indica que el PDP puede substituir el objeto determinado dentro de los mensajes RSVP. Contexto del mensaje Trayectoria adentro Objetos Política TSpec Flowspec Errorspec Elementos afectados x x ·— • Estado instalado de la TRAYECTORIA. ·— • Todos los mensajes del trayecto de salida para esta TRAYECTORIA. Trayectoria hacia fuera x x ·— ·— Resv adentro x ·— x ·— Esto restaura de la TRAYECTORIA (pero no del estado instalado de la TRAYECTORIA). • Estado instalado RESV (entrante e instalación del control de tráfico). • Todos los mensajes RESV salientes para este RESV. Resv Alloc ·— ·— x ·— Recursos instalados para esta sesión. Resv hacia fuera x ·— x ·— Este detalle restaura del mensaje RESV (pero no del estado instalado RESV ni de la asignación de control de tráfico). PathError adentro x ·— ·— x El mensaje remitido PATHERROR. PathError hacia fuera x ·— ·— x El mensaje remitido PATHERROR. ResvError adentro x ·— ·— x Todos los mensajes RESVERROR remitidos por este router. ResvError hacia fuera x ·— ·— x Este mensaje remitido detalle RESVERROR. Si un mensaje RSVP cuyo objeto fue substituido se restaura más adelante de la conexión en sentido ascendente, el PEP no pierde de vista el viejo y las nuevas versiones del objeto, y no interpreta incorrecto la restauración como cambio en el estado de la TRAYECTORIA o RESV. Para la información sobre cómo configurar a los POLIS para RSVP, vea el capítulo “configurando los POLIS para RSVP” en este libro. Subnetwork Bandwidth Manager RSVP y sus definiciones de clase de servicio son en gran parte independientes de las tecnologías de red subyacente. Esta independencia requiere que un usuario defina la asignación de RSVP sobre las Tecnologías del red secundario. La característica del Subnetwork Bandwidth Manager (SBM) contesta a este requisito para RSVP en relación con las redes de IEEE 802-based. SBM especifica un método de señalización y el protocolo para el control de admisión basado en LAN para RSVP fluye. SBM permite al Routers RSVP-habilitado y acoda 2 y acoda 3 dispositivos para soportar la reserva de los recursos LAN para los flujos de datos RSVP-habilitados. El SBM que señala el método es similar al de RSVP sí mismo. Las entidades de protocolo SBM tienen las características siguientes: • Resida en los dispositivos de la capa 2 o de la capa 3. • Puede manejar los recursos en un segmento. Un segmento es un segmento de la comprobación de la capa 2 compartido por uno o más remitentes, tales como los Ethernet compartida o un alambre del Token Ring. • Pueden convertirse los candidatos en un proceso de elección dinámico que señale un SBM como el administrador del segmento. Llaman el candidato elegido el Subnetwork Bandwidth Manager señalado (DSBM). El DSBM elegido es responsable de efectuar el control de admisión sobre los pedidos las reservas de recursos en un segmento manejado. Un segmento manejado incluye esas partes de interconectadas un LAN compartido que no sean separadas por DSBMs. La presencia de un DSBM hace el segmento manejado. Uno o más SBMs puede existir en un segmento manejado, pero puede haber solamente un DSBM en cada segmento manejado. Usted puede configurar una interfaz en el Routers conectado con el segmento para participar en el proceso de elección DSBM. El competidor configurado con la prioridad más alta se convierte en el DSBM para el segmento manejado. Si usted no configura a un router mientras que habilitan a un candidato y RSVP DSBM, después el sistema obra recíprocamente con el DSBM si un DSBM está presente en el segmento. De hecho, si un DSBM, identificándose como tal, existe en el segmento, el segmento se considera un segmento manejado y toda la expedición del mensaje RSVP será basada en las reglas de la expedición del mensaje SBM. Este comportamiento existe para permitir los casos en los cuales usted puede ser que no quiera una interfaz RSVP-habilitada en un router conectado con una interfaz manejada del segmento para hacer un DSBM, pero usted quisiera que obrara recíprocamente con el DSBM si uno es presente que maneja el segmento. La notaSBM no se soporta actualmente en los Token Ring LANE. El cuadro 7 muestra un segmento manejado en un dominio de la capa 2 que interconecte un conjunto de los hosts y de Routers. Cuadro 7 segmento manejado DSBM Cuando un cliente DSBM envía o adelante un mensaje de trayecto de RSVP sobre una interfaz asociada a un segmento manejado, envía el mensaje de trayecto al DSBM del segmento en vez a la dirección destino de la sesión RSVP, como se hace en el proceso convencional de RSVP. Como parte de su procedimiento del procesamiento de mensajes, el DSBM construye y mantiene un estado de la TRAYECTORIA para la sesión y observa el salto anterior de la capa 2 o de la capa 3 del cual recibió el mensaje de trayecto. Después de procesar el mensaje de trayecto, el DSBM adelante él hacia su dirección destino. El DSBM recibe el mensaje RSVP RESV y lo procesa de una forma similar a cómo RSVP sí mismo maneja la solicitud de reserva que procesa, basando el resultado en el ancho de banda disponible. El procedimiento es el siguiente: • Si no puede conceder la petición debido a la falta de recursos, el DSBM vuelve un mensaje RESVERROR al solicitante. • Si los recursos suficientes están disponibles y el DSBM puede conceder la solicitud de reserva, él adelante el mensaje RESV hacia los saltos anteriores usando el estado del trayecto local para la sesión. Para la información sobre cómo configurar SBM, vea “configurando el módulo del Subnetwork Bandwidth Manager”. Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R) Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental. © 2007 Cisco Systems, Inc. All rights reserved. © 1992-2013 Cisco Systems Inc. Todos los Derechos Reservados. Fecha de Generación del PDF: 21 Agosto 2013 http://www.cisco.com/cisco/web/support/LA/107/1075/1075588_signalling_oview_ps6922_TSD_Products_Configuration_Guide_Chapter.html
