SIMULADOR DE TRÁFICO ATM CON GARANTÍA DE SERVICIO

Tamaño: px
Comenzar la demostración a partir de la página:

Download "SIMULADOR DE TRÁFICO ATM CON GARANTÍA DE SERVICIO"

Transcripción

1 SIMULADOR DE TRÁFICO ATM CON GARANTÍA DE SERVICIO I. PRELIMINARES INTRODUCCIÓN Antecedentes de la simulación ASPECTOS GENERALES DE ATM Conmutación de paquetes a alta velocidad Arquitectura de un nodo ATM Modelo de referencia ATM Categorías de Servicio ATM Parámetros de la Calidad de Servicio Control de Congestión Redes ATM MOTIVACIONES Fiabilidad Garantía de servicio Funcionamiento de TCP Funcionamiento de TCP TCP sobre ATM Beneficios aportados por TAP Limitaciones de ATM frente a la GoS...19 II. LA PROPUESTA TAP INTRODUCCIÓN Conceptos fundamentales sobre agentes Sistemas multiagentes (SMA) ARQUITECTURA TAP El SMA-TAP Arquitectura del SMA-TAP Conmutadores AcTMs Colas de entrada GESTIÓN JUSTA DE COLAS Fair Queuing GPS, PGPS (WFQ) y PFQ Propuesta QPWFQ para TAP QLWFQ QPWFQ MECANISMOS DE CONTROL DE CONGESTIÓN Antecedentes, mecanismo EPD Propuesta EPDR...39 BASES DE LA SIMULACIÓN INTRODUCCIÓN

2 9. FUNCIONES Y ALGORITMOS DE GESTIÓN DE CONEXIONES Funciones y algoritmos de gestión de conexiones en las redes ATM reales Señalización Direccionamiento Enrutamiento CAC Connection Admission Control Tablas de enrutamiento de VCCs Funciones y algoritmos de gestión de conexiones de simswitch Señalización en la simulación Direccionamiento en la simulación Enrutamiento en la simulación El algoritmo CAC en la simulación Tablas de enrutamiento de VCCs en la simulación FUNCIONES Y PROCEDIMIENTOS PARA LA GESTIÓN DEL TRÁFICO Introducción Connection Admisión Control Usage Parameter Control Selective Cell Discard Traffic Shaping Explicit Forward Congestion Indication Resource Management using Virtual Paths Frame Discard Generic Flow Control ABR Flow Control CATEGORÍAS DE SERVICIO IMPLEMENTADAS Las categorías de servicio ABR y UBR ABR-l Modelo de servicio detallado para ABR-l Modelo de control de flujo para ABR-l Parámetros de servicio ABR-l Estructura de las células RM Comportamiento de la fuente Comportamiento del sumidero Comportamiento de los conmutadores Algoritmos en pseudocódigo UBR-l...78 SIMULACIONES SIMULACIONES La Topología Base Comportamiento del tráfico de tramas con relación al umbral Influencia del EPDR en la fragmentación Influencia del tamaño del búfer del conmutador congestionado Influencia del grado de GoS de las conexiones privilegiadas Influencia del tamaño de la memoria DMTE Influencia de la velocidad de salida de las fuentes EAAL Conclusiones Trabajos futuros BIBLIOGRAFÍA

3 1. Introducción I.PRELIMINARES El proyecto Simulador de tráfico ATM con GoS tiene como objetivo fundamental la creación de una herramienta multiplataforma específica y dedicada a comprobar las consecuencias e implicaciones de implantar la arquitectura TAP (Trusted and Active Protocol PDU transfer) en una red de tecnología ATM. Esta arquitectura aparece propuesta por D. José Luis González Sánchez en detalle en su tesis doctoral Protocolo activo para transmisiones garantizadas sobre una arquitectura distribuida y multiagente en redes ATM. Actualmente, tal y como se plantea la realización de este simulador, no conocemos una alternativa equivalente a la recogida en este proyecto ya que, aunque en la propia tesis se propone un simulador, el SSAcTM, partiendo desde cero, intenta ir más allá permitiendo el diseño de topologías diferentes y aumentando el nivel de realismo de simulación de tráfico en la medida de nuestras capacidades. La arquitectura TAP es novedosa por sus características: distribuida, activa y multiagente. El protocolo creado para la arquitectura ofrece transferencias garantizadas a un conjunto de privilegiado de conexiones VPI/VCI. Se propone también una extensión de la capa AAL-5 de ATM denominada EAAL-5 (Extended AAL type 5) usadas para la gestión de conexiones privilegiadas extremo-extremo. TAP ofrece garantía de servicio (GoS) cuando la red está perdiendo células pertenecientes a las conexiones privilegiadas y aprovecha los períodos de inactividad de los enlaces para hacer retransmisiones de las CPCS-PDU-EAAL-5 mediante el uso de mecanismos NACK. TAP es soportado por conmutadores ATM activos (denominados AcTM) que presentan una arquitectura diseñada específicamente para estos propósitos. Además, mediante técnicas software, intenta disminuir de forma justa la carga de los conmutadores; optimizar las retransmisiones de PDU; aliviar la implosión sobre las fuentes; evitar la fragmentación de las PDU y disminuir el interleaving de células, optimizando el goodput. El software de simulación de tráfico ATM con GoS que hemos desarrollado está formado por cuatro aplicaciones independientes pero relacionadas. Cada una de ellas dispone de un interfaz gráfico potente para permitir un entorno amigable de usuario. La programación de cada uno de los módulos que componen este programa está realizado en Java y la ejecución de los procesos requeridos puede realizarse de forma centralizada en PC s mono y multiprocesador gracias a su implementación multi-hilo. El simulador dispone de tres niveles de operación: el primero trata del diseño y análisis del comportamiento de los distintos dispositivos ATM (nivel de dispositivo), el segundo considera la construcción de una red ATM con conmutadores AcTM integrados (nivel de red), y el tercero se encarga de evaluar cualitativa y cuantitativamente el grado de servicio ofrecido por la red bajo estudio de extremo a extremo (nivel de usuario o servicio). 3

4 1.1. Antecedentes de la simulación Existe una tentación subyacente al proponer un nuevo simulador, que sería la de reformar o ampliar algunos de los ya existentes. Los paquetes de simulación que actualmente se usan y que se conocen ampliamente surgieron hace algún tiempo como herramientas de simulación de las redes ya existentes (Ethernet, Token-ring, FDDI, interconexión a través de redes WAN,...) Como ejemplo de éstos, se pueden citar el BONes DESIGNER, NS, GPSS/H, MODSIM, SES/Workbench, SIMAN, SIMSCRIPT, SLAMSYSTEM y OPNET. De todos ellos, sólo BONes DESIGNER, SES/Workbench y OPNET tienen módulos de comunicaciones y este último, dispone de un pequeño módulo de ATM completamente diferente a lo que se pretende hacer en este proyecto. Por tanto, no están pensados para la simulación de arquitecturas de conmutación como las que aquí se van a simular, con lo que si se quisiera reutilizar alguno de ellos al menos surgirían dos graves problemas. En primer lugar, su reconstrucción para la utilización en entornos ATM se prevé muy costosa y puede consumir demasiado tiempo. En segundo lugar, el tiempo necesario para la simulación de cualquier red sería excesivamente alto, haciendo altamente ineficaz su uso. Es pues necesario desarrollar un simulador específico para nuestro entorno y huir en lo posible de simuladores de propósito general. 4

5 2. Aspectos generales de ATM El Modo de Transferencia Asíncrono (ATM) es la base de un estándar internacional propuesto como un sistema de conmutación de paquetes para el transporte de datos basado en células de longitud fija y de pequeño tamaño (53 octetos). ATM se caracteriza también por ofrecer funciones de gestión de tráfico para la transferencia óptima de información en tiempo real (tráfico multimedia) y tiempo no-real (datos o imágenes estáticas), aportando la atractiva ventaja de diferentes flujos de información. Ha sido elegida por la ITU-T como base para la implementación de la RDSI-BA (Red Digital de Servicios Integrados de Banda Ancha) Sin embargo, debido a que ATM se trata de una tecnología muy novedosa y aún en proceso de implantación, a pesar de que muchos aspectos de la misma están resueltos, aún quedan muchos otros que son foco de atención de la comunidad investigadora que realiza propuestas para mejorar la tecnología. La arquitectura TAP es un ejemplo de ello. Debido a que aspiramos a movernos dentro del ámbito de las arquitecturas, protocolos, tráfico nativo ATM, etc., en el presente capítulo realizaremos una descripción de los aspectos básicos de la tecnología ATM. Esto ayudará al lector a familiarizarse con el entorno en el que se desarrollará nuestro simulador así como para situarse en un punto donde podamos presentarle más claramente la problemática que conlleva ofrecer garantía de servicio en conexiones extremoextremo, aspecto base de la tecnología TAP Conmutación de paquetes a alta velocidad Como ya hemos apuntado antes, ATM es la tecnología subyacente que hace posible la RDSI-BA como red integrada para todos los tipos de transferencia de información que se preveía que reemplazase en el futuro a todo el sistema telefónico y a todas las redes especializadas. Esta nueva red tendrá una velocidad de transmisión muy elevada, en comparación con todos los servicios y redes existentes, y hará posible ofrecer una gran variedad de servicios nuevos. Las nuevas necesidades de la RDSI-BA orientaron las comunicaciones hacia la conmutación de paquetes en alta velocidad para contar simultáneamente con las ventajas de las redes de circuitos y las redes de paquetes. Esta nueva tecnología debería ser capaz de proporcionar anchos de banda variables, ser transparente a los protocolos utilizados y soportar una gama amplia de servicios con soluciones específicas de velocidad, sincronización y latencia. La idea en la que se basa ATM consiste en transmitir toda la información en paquetes pequeños de tamaño fijo, llamados células o celdas (Cells). El uso de una tecnología de conmutación de células es una ruptura drástica con respecto a la conmutación de circuitos dentro de un sistema telefónico. Son muchas las razones por las que se escogió la conmutación de células, entre ellas están las siguientes. Primero, la conmutación de células es altamente flexible y puede manejar con facilidad tanto tráfico de velocidad constante como variable. Segundo, a las velocidades tan altas que se contemplan, la conmutación digital de las células es más fácil que el empleo de las técnicas tradicionales de multiplexación, en especial si se utiliza fibra óptica. Tercero, tan solo la conmutación de células, no la de circuitos, puede proporcionar la difusión, 5

6 esencial para diversos servicios como por ejemplo la distribución de televisión. En resumen, las ventajas obtenidas con la conmutación de celdas son una baja latencia que permite soportar datos isócronos y una eficiente conmutación hardware gracias al tamaño constante de los paquetes Arquitectura de un nodo ATM ATM puede considerarse como una tecnología de conmutación de paquetes de alta velocidad con unas características particulares: - Los paquetes son pequeños y de tamaño constante. - Es una tecnología de naturaleza conmutada y orientada a conexión. - Los nodos que componen una red no tienen mecanismos para el control de errores o control de flujo. - La cabecera de las células tiene una funcionalidad limitada. Simplificando al máximo podemos ver que una red ATM está compuesta por nodos de conmutación, elementos de transmisión y equipos terminales de usuarios. Los nodos son capaces de encaminar la información empaquetada en células a través de unos caminos conocidos como Conexiones de Canal Virtual. El encaminamiento, en los nodos conmutadores de células, es un proceso hardware, mientras que el establecimiento de conexiones y el empaquetamiento/desempaquetamiento de las células son procesos software. Figura 2.1 Esquema de comunicación con ATM Las células constituyen la unidad de transferencia en las redes ATM que, como hemos dicho antes son de tamaño fijo y relativamente pequeñas. De los 53 octetos totales, 5 bytes se emplean en las cabeceras y los 48 restantes se emplean para la carga útil de datos. En la figura 1.2 se puede observar los dos formatos de células ATM con sus correspondientes campos y tamaños. 6

7 El hecho de que haya dos formatos distintos se debe a que uno es usado en el interfaz entre el usuario y la red (UNI) y el otro es el que utilizan los conmutadores de la red entre si (NNI). Figura 2.2 Formato de células ATM Cada célula presenta un campo VPI y otro VCI. El conjunto de ambos especifica a un Canal Virtual (VC) que es una representación de una conexión unidireccional entre dos usuarios. El primero identifica la Ruta Virtual (Virtual Path) y el segundo un Canal Virtual (Virtual Channel) específico dentro de cada VP. El campo PT (Payload Type) se usa para indicar el tipo de información contenida en el campo de carga de datos de la célula. El bit CLP (Cell Loss Priority) lo emplea el emisor para especificar la prioridad deseada de descarte de células en el caso de congestión en la red. Un CLP=1 indica que la célula es de baja prioridad y por lo tanto descartable. El campo HEC (Header Error Control) es un código de redundancia cíclico usado para detectar errores en la cabecera. A continuación de la cabecera vienen 48 bytes de carga útil. Sin embargo, y como veremos en el módulo II no todos los 48 bytes están disponibles para el usuario, pues algunos de los protocolos AAL ponen sus cabeceras y sus terminaciones dentro de la carga Modelo de referencia ATM Ya que la arquitectura TAP realiza aportaciones al modelo arquitectónico de ATM debemos entender cómo se estructura éste para poder comprender así las aportaciones de TAP a su funcionamiento. El modelo ATM se apoya en las capas Física, ATM y de Adaptación ATM, cada una de ellas con una serie de funciones específicas para permitir la transferencia de células. En la arquitectura TAP la capa física permanece intacta y se centra sobre todo en la capa de adaptación ATM. Las uniones de cada una de las capas se presentan en el siguiente cuadro: 7

8 Figura 2.3 Modelo de referencia de ATM respecto al RM-OSI En la figura 2.3 se presenta un esquema del modelo ATM atendiendo a las capas que implementa cada elemento de la red. Puede observarse como los conmutadores de red tan solo implementan las dos primeras capas ya que el tráfico entre ellos es ATM nativo. Sin embargo los nodos o conmutadores locales sí que necesitan de la capa AAL para ajustar el tráfico no ATM que pudiera generar un nodo terminal de usuario que, como podemos observar, pueden hacerlo a través de cualquier protocolo de comunicación como TCP/IP. La arquitectura ATM usa un modelo lógico para describir su funcionalidad. La funcionalidad de ATM corresponde a la capa física y parte de la capa de enlace del modelo de referencia OSI. El modelo de referencia ATM está compuesto por los siguientes planos : - Control: Este plano es responsable de generar y gestionar las demandas de señalización. - Usuario: Responsable de gestionar la transferencia de datos. - Gestión: Contiene dos componentes o Gestión de capas: Gestiona funciones específicas de las capas, como detección de fallos y problemas del protocolo. o Gestión de planos: Gestiona y coordina funciones relacionadas con el sistema completo. El modelo de refencia ATM se compone de las siguientes capas: - Capa física: Análoga a la capa física del RM-OSI, gestiona la transmisión dependiente del medio. 8

9 - Capa ATM: Junto con la capa de adaptación ATM, la capa ATM es análoga a la capa de enlace del RM-OSI. La capa ATM es responsable de establecer conexiones y de transferir células a través de la red ATM. Para esto, usa la información que se encuentra en la cabecera del las células ATM. - Capa de adaptación ATM (AAL, Adaptation ATM Layer): Junto con la capa ATM, es análoga a la capa de enlace RM-OSI. AAL es responsable de aislar los protocolos de las capas superiores de los detalles de los procesos ATM. Finalmente, las capas superiores a AAL recogen los datos de usuario, los coloca en paquetes y los transfiere a la capa AAL Categorías de Servicio ATM La tecnología ATM fue diseñada y desarrollada para soportar e integrar varias clases de servicio. Cada cliente, en la fase de establecimiento de la conexión, negociará con la red la clase de servicio que requiere su comunicación. Estos servicios genéricos son proporcionados por cuatro tipos de AAL, que introducen niveles específicos de protocolo, para proporcionar la Calidad de Servicio (QoS) adecuada para cada tipo de tráfico. Las clases de servicio que normalizadas por la ITU-T son cuatro: DBR (Deterministic Bit Rate) SBR (Statistic Bit Rate) ABR (Avaliable Bit Rate) y ABT (ATM Block Transfer) Además de las clases de servicio recomendadas por la ITU-T el ATM Forum especifica un conjunto de Categorías de Servicio (CoS), algunas de ellas equivalentes a las capacidades de servicio mencionadas anteriormente. Las categorías de servicios comúnmente usadas por los proveedores son las siguientes: - La clase CBR (Constant bit Rate) proporciona una velocidad de acceso constante y una relación sincronizada entre los usuarios; en otras palabras es un servicio que emula las prestaciones de un circuito. Es equivalente a la DBR de la ITU-T. - La clase VBR (Variable Bit Rate) se divide en dos subclases, la de tiempo real (RT- VBR) y la de tiempo no real (NRT-VBR), respectivamente. La RT-VBR es para servicios que tienen una tasa de bits variables en combinación con requisitos estrictos de tiempo real. La otra subclase de VBR es para tráfico en el que la entrega a tiempo es importante pero la aplicación puede tolerar una cierta cantidad de fluctuación. Equivalente a la SBR de la ITU-T. - La clase ABR (Avaliable Bit Rate) se diseñó para tráfico a ráfagas cuya gama de ancho de banda se conoce aproximadamente. Permite a los usuarios finales pedir a la red cuánto ancho de banda es necesario para una conexión dada pero evita tener que comprometerse con un ancho de banda fijo. La ABR es la única categoría de servicio en la que la red proporciona tasa de retroalimentación al transmisor solicitándole que disminuya la velocidad al ocurrir congestionamientos mediante las denominadas células RM. - Por último la UBR (Unespecified Bit Rate) No garantiza ni el caudal de tráfico ni el retardo. Esta categoría se adapta bien al envío de paquetes IP, puesto que IP tampoco hace promesas respecto a la entrega. 9

10 Parámetros de la Calidad de Servicio Tanto en el caso del tráfico de datos como en el de las aplicaciones multimedia, la noción de QoS o calidad de servicio es muy importante y está definida como un conjunto de parámetros que representan las propiedades del tráfico. Desde una perspectiva formal y estándar, existen consideraciones diferentes para el punto de vista del usuario y del proveedor de la red a la hora de establecer los parámetros de la QoS. En nuestro caso vamos a tratar de forma genérica la QoS sin entrar en consideraciones formales, por lo que podemos decir que para nosotros la QoS es "la habilidad para definir o predecir el rendimiento de una red y ofrecer mejores servicios a una CoS específica". En general existen los siguientes cuatro parámetros básicos de QoS: el rendimiento (throughput), el retardo (delay), la variabilidad de retardo (jitter) y por otro lado la fiabilidad (reliability) Además de estos cuatro parámetros, que ya aportan grandes ventajas con respecto a otras tecnologías, existen una extensa serie de parámetros directamente relacionados con la QoS. En la tabla 2.1 se muestran algunos de estos parámetros que se usan para caracterizar el tráfico que genera cada una de las fuentes, los cuáles están directamente con cada una de las CoS ya comentadas. Parámetro Descripción Significado PCR Peak Cell Rate Máxima velocidad a la que se envían células SCR Sustained Cell Rate Velocidad media de células a largo plazo MCR Minimun Cell Rate Velocidad de células mínima CDVT Cell Delay Variation Tolerance Máxima fluctuación de retardo de células CLR Cell Loss Ratio Tasa de células perdidas o entregadas con retardo CTD Cell Transfer Delay Tiempo que tarda una célula en llegar extremo-extremo CDV Cell Delay Variation Variación entre los retardos de llegada de células. CER Cell Error Ratio Porcentaje de células erróneas que llegan al destino SECBR Severely-Errored Cell Block Ratio Porcentaje de tramas que contienen células erróneas CMR Cell Missinsertion Rate Células entregadas a destino erróneo por errores en cabecera MBS Maximum Burst Size Máximo tamaños de ráfaga permitido MFS Maximum Frame Size Máximo tamaño de trama permitido IBT Intrinsic Burst Tolerance Tolerancia a la aparición de ráfagas ECR Explicit Cell Rate Velocidad máxima de células explícitas autorizada a la fuente BCR Block Cell Rate Velocidad pico de célula de bloque Tabla 2.1 Parámetros de QoS 10

11 Control de Congestión Hemos visto que uno de los aspectos principales en la transmisión de células en ATM es la falta de comprobación de errores del payload. Por tanto un error en una célula puede pasar inadvertido hasta que ésta llega al extremo destino de su VP. Sin embargo, a pesar de la gravedad de estos errores de transmisión, no son el principal problema que pueden experimentar las células ya que son relativamente poco frecuentes (la fibra óptica tiene una tasa de errores de 10EXP-12) Un problema más grave y menos predecible es el de la congestión, provocado en los conmutadores cuando se les exige un rendimiento superior al que son capaces de ofrecer. Nos encontramos con dos tipos de congestión principales: a largo plazo provocada por la generación de un tráfico superior al que puede manejar la red y, por otro lado, la congestión producida a corto plazo que es causada por fuentes que generan tráfico a ráfagas que no mantienen un comportamiento estable en sus parámetros. Para solventar estos dos problemas se han propuesto múltiples: Control de admisión. Si la red no puede encontrar un circuito virtual que garantice las necesidades que el usuario expresa en el transcurso del procedimiento de establecimiento de la conexión, no permitirá que ésta se lleve a cabo para evitar que su entrada pueda perturbar el buen estado de la red y de las conexiones que ya han sido admitidas. Esta labor la realiza la función CAC (Connection Admission Control) Reserva de recursos. Como complemento al CAC en cada conmutador se reservan recursos para cada conexión establecida con el fin de que no sean tomados por otra conexión. La reserva de recursos puede hacerse respecto a cualquiera de los parámetros de QoS que hemos descrito anteriormente. Control basado en velocidad explícita. Como ya dijimos anteriormente la CoS ABR utiliza células RM generadas con una frecuencia fija. Cuando un conmutador detecta la falta de alguna célula RM prevista lo interpreta como la existencia de congestión en algún punto entre el destino y el conmutador que lo detecta. Mediante este mecanismo el emisor tiene la posibilidad de rebajar su tasa de transferencia cuando ocurre esto ante la posibilidad de congestiones. El protocolo TAP utiliza un mecanismo parecido para ofrecer garantía de servicio a las conexiones privilegiadas. Aunque, como hemos visto, existen mecanismos de control de congestión, las congestiones pueden aparecer de forma indeterminista y en estos momentos es cuando tendrá sentido el protocolo de recuperación de células (PDUs) punto-a-punto propuesto en TAP en lugar del mecanismo extremo-a-extremo usado por los protocolos AAL y superiores de los terminales ATM Redes ATM Las redes ATM están orientadas a conexión, por lo que antes de empezar cualquier transmisión de información se ha de proceder al establecimiento del enlace. Los dos identificadores en la cabecera de la célula (VPI y VCI) permiten distinguir dos tipos distintos de 11

12 conexión: el campo VPI (Virtual Path Identifier) identifica un trayecto virtual y el VCI (Virtual Channel Identifier) un canal virtual, pudiendo existir varios VCs por VPs y varios VPs por cada canal físico. Las redes ATM se muestran adecuadas para tratar cualquier tipo de información basándose en señales digitales. Las 5 capas de adaptación ATM (las AALs) son las encargadas de adaptar el flujo de señales binarias generadas por los terminales para poder ser tratadas por los conmutadores ATM, segmentándolos en bloques de 48 bytes y reagrupándolos después. ATM resulta particularmente interesante para proporcionar instantáneamente un gran ancho de banda en aquellas aplicaciones con un alto nivel de impulsividad, como son las propias de las redes locales; así, pues, esta técnica de multiplexación encuentra una de sus principales aplicaciones en la interconexión de LANs dentro de entornos privados (HUBs ATM). Su introducción en la red pública, al requerir elevadas inversiones y largos procesos de aceptación, se realizará progresivamente y en función de la existencia de aplicaciones multimedia y de equipos de acceso ATM suficientemente flexibles y económicos para ser utilizados masivamente, sirviendo, por ejemplo, para la interconexión de las islas ATM privadas. Por otra parte, el servicio de vídeo bajo demanda permite el transporte de imágenes digitales, comprimidas o no, a alta velocidad. En este caso la velocidad binaria puede variar (VBR). Figura 2.4 Interconexión ATM en LAN-MAN-WAN 12

13 3. Motivaciones En este capítulo vamos a profundizar sobre los motivos que impulsaron la creación de la arquitectura TAP que, como ya hemos apuntado con anterioridad, tiene unos objetivos específicos y bien definidos. Hemos dicho que TAP ofrece Garantía de Servicio (GoS) a un conjunto de privilegiado de conexiones pero qué se entiende por garantía de servicio? Qué relación tiene con respecto a la fiabilidad? Cuáles son los antecedentes y alicientes que provocaron la creación de este servicio? Qué ventajas podríamos obtener si lo implantáramos en una red ATM? En los siguientes apartados pretendemos contestar a todas estas preguntas. Con estos objetivos presentes, primeramente nos centraremos en el concepto de fiabilidad que, como ya dijimos en el anterior capítulo, es un parámetro básico de la QoS, y prestaremos especial atención a las circunstancias que hacen una conexión más o menos fiable y a los mecanismos de que dispone la red para proporcionan el grado de fiabilidad deseado. Seguidamente introduciremos el concepto de garantía de servicio y veremos qué relación tiene con la fiabilidad. En los dos siguientes apartados estudiaremos someramente el protocolo TCP y su funcionamiento sobre ATM para mostrar cómo los protocolos superiores intentan resolver las deficiencias que en este sentido presentan las redes ATM. Por último, y una vez ya tenemos claro los anteriores conceptos, centraremos nuestra atención en los procesos que intervienen a la hora de aportar GoS a las conexiones y poner de relieve los problemas y carencias a los que se enfrenta una red ATM actual a la hora de proporcionar este servicio a un conjunto de conexiones privilegiadas Fiabilidad La tecnología ATM se caracteriza por su flexibilidad a la hora de proporcionar distintos grados de servicio a las conexiones según el tipo de tráfico que generen. Esta flexibilidad nace de la posibilidad de negociar diversos parámetros de QoS como througput, delay, jitter y reliability (fiabilidad) Por lo tanto una fuente ATM tiene la posibilidad de exigir un cierto grado de fiabilidad a la red para las conexiones que quiera establecer. Antes de proseguir es necesario dar una definición al concepto de fiabilidad según se entiende en el ámbito de las redes ATM. En comunicaciones el concepto de fiabilidad está claramente aceptado como "la forma de aportar a las conexiones extremo-extremo garantía plena de que la información que transfieren llega sin ningún error o, si aparecen errores, todos puedan ser detectados y corregidos". De esta definición podemos extraer tres deducciones inmediatas: la primera y más obvia, en una comunicación puede haber errores; en segundo lugar, es posible detectar y solventar esos errores; en tercer y último lugar, ya que la fiabilidad es un parámetro negociable, deducimos que según el grado requerido de fiabilidad puede no ser necesario corregir un error. Vayamos por partes; según el primer aspecto vemos que los errores en las transmisiones son posibles pero qué es un error? Un error puede considerarse como la manifestación de un fallo. En las redes ATM los posibles fallos en su funcionamiento pueden provocar tres tipos de errores que afectan directamente a la información que transportan: bits erróneos en el payload de una célula, errores de conmutación debido a bits erróneos no detectados en la cabecera de una célula y bits perdidos en congestiones. Según las investigaciones realizadas se demuestra que las 13

14 pérdidas por congestión son la forma predominante de error. Esto es así ya que los otros dos tipos de errores son predominantemente consecuencia del ruido inducido por la línea de comunicación. Como ya sabemos ATM fue diseñado para usarse en fibra óptica y la fibra es altamente fiable con una tasa de error de 10EXP-8 a 10EXP-12, o sea, que por cada billón de bits que pasa por un tramo de cable tan solo uno de ellos sufre alteración. Por lo tanto el principal problema al que se enfrenta una red a la hora de proporcionar conexiones fiables es el de la pérdida de células por el agotamiento de recursos cuando muchas compiten con ellos, esto es, la congestión. Llegados a este punto nos vamos a centrar sobre el segundo aspecto deducido de la definición de fiabilidad: la detección y resolución de errores. En cuanto a la detección de errores, ATM nos proporciona varios mecanismos. El de más bajo nivel consiste en un código de redundancia cíclico de 8 bits presente en el capo HEC de las células (ver capítulo 2 figura 2.2) utilizado para detectar errores en la cabecera. Por las características de CRC y del medio de transmisión se calcula que, a velocidad OC-3, pasará un encabezado de célula errónea cada años. Así vemos que, aunque posible, es casi nula la probabilidad de que una célula con cabecera errónea pase desapercibida. Sin embargo para el cuerpo de una célula, a este nivel, no existe ningún mecanismo que nos permita saber si un bit es erróneo o no. Esto se resuelve con un segundo nivel de control de errores mediante varios y diversos mecanismos aplicados a paquetes de células. Así pues, en el nivel AAL se realiza una comprobación de la integridad de las células que componen un PDU-AAL (ya sea AAL-1, AAL-2, AAL-3/4 ó AAL-5) Es importante destacar que las tramas AAL sólo tienen sentido en los terminales de la comunicación por lo que este control es únicamente extremo-extremo. Por lo tanto, si una célula perteneciente a una trama AAL se pierde o presenta bits erróneos por algún motivo en el transcurso de una transmisión, el suceso solo será detectado cuando se intente reensamblar la trama y se compruebe, mediante el mecanismo de detección de errores específico de cada tipo, que la trama no es correcta. Mientras tanto el resto de las células de la trama corrupta habrán estado circulando por la red ocupando recursos inútilmente. Esto afecta muy negativamente al rendimiento de la red de muy diversas formas dependiendo de la técnica utilizada para la corrección del error. Efectivamente la resolución de errores en una red ATM puede realizarse mediante retransmisiones extremo-aextremo, lo que se denominan técnicas ARQ (Automatic Repear Request) Según esta técnica el anterior error provocará una petición de retransmisión y la consecuente retransmisión de la PDU completa por parte del extremo emisor. Si nos ponemos en la situación en la que la célula se ha perdido como consecuencia de una congestión, el hecho de pedir retransmisiones extremo-aextremo de tramas enteras para subsanar el error podría acarrear un empeoramiento de la situación. Al pedir estas retransmisiones en vez de disminuir el tráfico para minimizar riesgos de congestión lo que hacemos es todo lo contrario. Es la situación del perro que se muerde la cola, cuanta más congestión hay más células se pierden y más retransmisiones se solicitan; cuantas más retransmisiones se solicitan más células se han de transmitir y más congestiones se provocan. Un problema más grave es el de la implosión y se produce por peticiones de retransmisiones en conexiones punto-multipunto donde cada destino realizará su propia petición de retransmisión al origen estando éste obligado a responder a todas ellas. La otra técnica alternativa es el FEC (Forward Error Correction) y se trata de corregir errores gracias la codificación de información redundante junto con los datos con el fin de reconstruir los datos originales en caso de error. FEC permite por tanto la recuperación sin necesidad de retransmisiones sin embargo añade sobrecarga por cabeceras y también código redundante cuando la red está experimentando congestiones. Cabe señalar que existen propuestas de técnicas híbridas ARQ-FEC pero la aplicación de éstas a tráfico multipunto es una labor muy compleja y problemática. 14

15 Ya hemos visto cómo los errores en las transmisiones son posibles, detectables y solventables. Sin embargo como hemos dejado entrever anteriormente, la reparación de un error puede no ser necesaria e incluso puede resultar perjudicial. Pongámonos en la situación de estar escuchando una cadena de radio digital mediante una conexión ATM en nuestro computador. Puede resultar aceptable en esta situación el error en un bit o la pérdida una célula de vez en cuando ya que el oído humano, al tener una sensibilidad limitada, no detectaría este error. Sin embargo sería inaceptable la petición de retransmisión de toda una trama AAL para recuperar una posible célula perdida ya que, aparte de que podría provocar un desorden en la recepción de PDUs, las aplicaciones en tiempo real, como la del ejemplo, no toleran un elevado retardo por lo que la información de la emisora podría resultar ininteligible. Por lo tanto el grado de fiabilidad requerido por una conexión está relacionado directamente con el tipo de información que transporta y sus exigencias particulares Garantía de servicio La propuesta de arquitectura TAP introduce el concepto de Garantía de Servicio (GoS) En su caso, no se pretende centrarse plenamente en el ámbito de la fiabilidad sino "encontrar un mecanismo que aporte a las transferencias ATM su garantía de servicio en el caso de que aparezcan congestiones en los conmutadores y, además que, cuando esto se produce, pueda ser solventado de forma local a los conmutadores congestionados sin implicar a toda la red para optimizar el goodput". El protocolo propuesto no se considera fiable en el estricto sentido de la palabra ya que no se comporta como tal, sino que lo que aporta es un elevado grado de confianza de servicio a las conexiones que lo utilizan. El objetivo de TAP no es por tanto la búsqueda de una fiabilidad completa en las conexiones, cosa que ATM ofrece por muy diversos métodos a costa de sobredimensionar las cabeceras de las células o PDU ATM, y con retransmisiones extremo-a-extremo. La GoS va un paso más allá de la fiabilidad en el sentido de que aporta mecanismos que intentan atajar el problema de la pérdida de células desde su raíz, esto es, proponiendo un mecanismo de retransmisiones al mismo tiempo que intenta evitar las congestiones en los conmutadores. Para el protocolo TAP la GoS se deriva directamente del parámetro fiabilidad y puede verse como un nuevo parámetro de QoS Funcionamiento de TCP El protocolo TCP se ha convertido en el estándar de comunicaciones de datos. Se trata de un protocolo fiable de la capa de transporte de la arquitectura TCP/IP que usa un control de error y un control de flujo basados en ventana y se encarga del enrutamiento de paquetes en internet con el control extremo-a-extremo. En la actualidad las redes ATM se están usando como la tecnología para soportar todo tipo de tráfico, pero con destacable predominio de los protocolos TCP/IP. Las diferencias entre ambas tecnologías se muestra como un serio obstáculo a la hora de mandar segmentos TCP a través de una red ATM y pretender mantener el throughput a niveles óptimos. En este apartado veremos brevemente cómo funciona TCP/IP y cómo reacciona ante las congestiones para poder entender mejor cómo puede degenerar el goodput de una red ATM que transporta tráfico TCP. 15

16 Funcionamiento de TCP La unidad de datos de protocolo en TCP se denomina segmento. Un segmento consiste en una cabecera de 20 bytes (más una parte opcional) seguida una parte de datos. En conjunto, el tamaño máximo de un segmento TCP no puede sobrepasar los 65,535 bytes. Un segmento demasiado grande para transitar por una red puede dividirse en varios segmenteos mediante un enrutador. Cada segmento nuevo recibe sus propias cabeceras TCP e IP, por lo que la fragmentación en los enrutadores aumenta la carga extra total. El protocolo básico usado por las entidades TCP es el protocolo de ventana corrediza de tamaño variable. El protocolo TCP es en la actualidad un conjunto de algoritmos que envían paquetes a la red sin ningún tipo de reserva previa, pero que son capaces de reaccionar ante determinados eventos de la misma. Entre estos algoritmos destaca el Control de Congestión y el de Recuperación de Segementos Perdidos. Para poder llevar esto a cabo, cada emisor mantiene dos ventanas: RWND (Receiver Window) y CWND (Congestion Window). Cuando se envían paquetes se usa la ventana más pequeña de estas dos. Al establecerse una conexión, el transmisor asigna a la ventana de congestionamiento el tamaño de segmento máximo usado por la conexión; entonces envía un segmento máximo. Por cada asentimiento positivo recibido antes de terminar el temporizador, la ventana de congestión es aumentada al doble de su valor. La ventana de congestionamiento sigue creciendo exponencialmente hasta ocurrir una terminación de temporización o alcanzar el tamaño de ventana receptora. Este algoritmo se llama Slow Start. El control de congestiones utiliza un parámetro, el umbral, inicialmente de 64 Kbytes. Cuando aparece congestión, por ejemplo detectada por un timeout, el valor del umbral es puesto a la mitad del valor actual de la ventana de congestión, la ventana de congestión es puesta a 1 segmento y la fase Slow Start es reiniciada de nuevo. Si no ocurren más terminaciones de temporización, la ventana de congestionamiento continuará creciendo hasta el tamaño de ventana del receptor. Un transmisor que llegue al umbral en su ventana de congestión entrará en la fase de Congestion Advoidance en la que la ventana de congestión aumentará de forma lineal al contrario de su crecimiento exponencial durante la fase de Slow Start. En realidad, en última instancia, la velocidad de transmisión de TCP viene determinada por el RTT (round tip time), ya que el emisor envía cada RTT el tamaño de datos determinado por la ventana de congestión. Por tanto, como se puede ver, TCP ajusta su ventana para reflejar las condiciones de la red de forma reactiva, esto es, cuantas más congestiones se produzcan más pequeña será la ventana al mismo tiempo que crecerá más lentamente. De esto se deduce que a medida que se incremente la pérdida de paquetes, la eficiencia de TCP cae sustancialmente. En [*] se realiza un estudio para comprobar el comportamiento del ancho de banda en una red TCP con respecto a la porbabilidad de errores. En él se comprueba algo que intuitivamente se observa a partir del propio funcionamiento de TCP y es cómo la probabilidad de perdida acaba determinando el ancho de banda de una fuente TCP. En la gráfica 3.1 obtenida a partir de una simulación en ns se puede observar cómo a medida que se aumenta la probabilidad de pérdida en un enlace disminuye el ancho de banda logarítmicamente hasta acercarse a una evolución lineal cuando la probabilidad de pérdida desciende, que es lo que intenta TAP. 16

17 Figura 3.1 Probabilidad de pérdida respecto al Ancho de Banda En este mismo estudio también se ha considerado el efecto de N fuentes TCP compartiendo un enlace partiendo de la posibilidad de que ese enlace pueda convertirse en un posible cuello de botella determinado por el tamaño de la cola del router (B). Realiza una aproximación a la predicción de probabilidad de pérdida de paquetes: ((FORMULA P=0,75 N^2/ B^2)) Puede deducirse por esta fórmula que en la probabilidad de pérdida influye directamente la capacidad de almacenamiento de paquetes en las colas de los routers comportándose éstas como un punto de congestión para el tráfico. Como ya veremos en el módulo II en la arquitectura TAP se ha incluido un módulo de memoria adicional para propósitos específicos denominada DMTE. Esto contribuye de forma directa a aumentar el tamaño del buffer y en vista de la fórmula anterior a conseguir disminuir la probabilidad de pérdida P TCP sobre ATM Debido a sus características, las CoS ABR y UBR son la propuesta estándar para soportar el tráfico de datos. Sin embargo diversos estudios demuestran que TCP sobre UBR experimenta una apreciable degradación en el funcionamiento en cuanto a la justicia, requiriendo además de un tamaño de buffer relativamente grande, incluso con pocas conexiones. Sin embargo cuando se emplea la CoS ABR con esquemas de realimentación de velocidad explícita ofrecen a TCP mejor comportamiento en cuanto a justicia y aprovechamiento de los enlaces, y todo ello, con tamaños de buffer menores que con UBR. Uno de los principales problemas que experimentan las fuentes de tráfico TCP cuyos segmentos son transferidos sobre ATM es que, al usarse como indicación de congestión la propia pérdida de paquetes, esto provoca que la gestión de las congestiones se realice cuando ya es demasiado tarde. Es decir, cuando el buffer se llena, el conmutador descarta los paquetes, el receptor detecta la pérdida y éste avisa al emisor que acaba reaccionando con la retransmisión de los paquetes perdidos. Se impone por tanto la necesidad de aportar mecanismos más ágiles para la 17

18 resolución de las congestiones de tráfico TCP que es transferido sobre tecnología ATM. Además existen muchas otras características diferenciadoras requiriéndose en consecuencia soluciones que resuelvan los problemas de rendimiento provocados por la integración de ambas tecnologías. Parece lógico que estas soluciones estén en la línea de realizar cambios en los conmutadores ATM dentro de la red. En el caso de TAP se enfrenta a estos problemas actuando dentro de la misma red con mecanismos hardware (conmutadores AcTMs) y también software (SMA con protocolo TAP) Beneficios aportados por TAP A parte de los beneficios, llamémosles secundarios, apuntados en los anteriores apartados, la motivación de TAP se centra en encontrar soluciones para evitar el negativo problema de las retransmisiones extremo-a-extremo. TAP se enfrenta a este problema resolviendo las retransmisiones de forma local a donde se producen para evitar el coste del tiempo RTT total de la red y emplear sólo el RTT del enlace donde se produce la congestión. Un RTT alto es un problema bastante grave en las redes de banda ancha. Veamos el por qué de este problema mediante un ejemplo: La electricidad se transmite en un cable de cobre a 2/3 de la velocidad de la luz. La luz en fibra óptica se transmite también a una velocidad que es 2/3 de la que alcanza en el vacío. Si disponemos de una línea transcontinental de 3000 Km, el retraso que experimenta una señal es de 3000/ = 15 ms. Supongamos que queremos enviar 1 Mb de datos por esa línea a 64 Kb/s y esperar la confirmación. Sólamente bombear a la línea el Mb lleva 1000/64 = 15.6 segundos. El retraso de propagación del impulso eléctrico es de * 2 = 0.03 segundos, que no es significativo frente a los 15.6, de modo que la distancia entre máquinas no es un factor que influya en el diseño del sistema global. Consideremos ahora la instalación de adaptadores ATM en ambas máquinas a una velocidad de 622 Mbs. Ahora poner en la línea 1 Mb supone 1/622 = s. Un retardo de propagación de 0.03 segundos, no sólo sí es significativo frente a segundos que se emplea en sacar el fichero a la línea, sino que es 18 veces mayor. Se tarda muchísimo más en que el primer bit llegue al otro extremo que en poner en el cable el Mb entero. Desde que comienza el envío hasta que vuelve la confirmación transcurren segundos, de los cuales la línea está ocupada segundos y ociosa 0.03 segundos, es decir, el 95% del tiempo. Un aumento de la velocidad de transmisión no provoca más que un menor aprovechamiento de la línea, que se aproxima asintóticamente al 100%. En el escenario descrito hemos supuesto una red ideal en la que no se produce ningún problema debido a congestiones o a bits erróneos. Fácilmente podemos entender que cualquier tipo de retransmisión debida a estos problemas acaba agravando aún más el problema descrito, ya que se multiplica el tiempo RTT mientras el tiempo de inactividad de la fuente se mueve a valores cercanos a 0. Con TAP se realizan las retransmisiones de forma local por lo que se consigue decrementar la probabilidad de pérdida con el consiguiente efecto sobre el throughput de TCP que evita los retardos debidos al RTT extremo-a-extremo. Se consigue así maximizar el goodput con una mínima pérdida de paquetes en el nivel TCP y con un retardo mínimo de células en el nivel ATM. 18

19 3.5. Limitaciones de ATM frente a la GoS En el apartado 3.2 introdujimos el concepto de GoS como un parámetro adicional derivado de los parámetros generales de QoS y cómo TAP pretende llegar a proporcionar GoS a un conjunto de conexiones privilegiadas. En este apartado vamos a indicar las limitaciones que impiden ofrecer a través de ATM el concepto de GoS. El primero y más importante problema es la imposibilidad de ATM de disponer de fiabilidad total sin afectar al buen rendimiento de la red. Una red ATM asume que pueden producirse pérdidas, de forma que la resolución de las mismas quedan delegadas en protocolos de capas superiores. Ni las células ATM ni las unidades de transferencia mayores de la capa AAL disponen de números de secuencia lo que impide la identificación de las que se pierden cuando la red experimenta congestiones. Por lo tanto, como en el anterior caso, la detección de datos perdidos es tarea de los protocolos superiores que, como sabemos, repercute en la eficiencia de la red por la necesidad de realizar retransmisiones e-e. Si se quieren suprimir las retransmisiones e-e para las conexiones con GoS es necesario un mecanismo que permita a los conmutadores AcTMs solicitar retransmisiones p-p de las tramas perdidas cosa que no está especificado en la actualidad por ATM. Además, debido a las características propias de la GoS y para proporcionar ésta sin degradar el rendimiento de una VPN son necesarios mecanismos que eviten la fragmentación de tramas y la mezcla de células pertenecientes a tramas distintas en una transimisión (lo que se conoce como interleaving). 19

20 II. LA PROPUESTA TAP 4. Introducción Lo primero que hay que exponer en esta introducción es la definición de agente. El concepto de agente puede ser estudiado desde muy distintos puntos de vista por lo que no existe un consenso claro en su definición. Uno de los ámbitos de acción de los agentes es precisamente el de los sistemas de telecomunicación, porque los agentes pueden dotar a las redes de características de las que carecen en la actualidad. Genéricamente, podemos decir que un agente es una entidad con objetivos, que alcanza ejecutando una serie de acciones, mediante un dominio de conocimiento y situado en un entorno concreto. Podemos hablar de sistemas multiagentes como un grupo de agentes que se comunican de algún modo entre sí. También existe controversia acerca de la definición de redes activas. Estas redes se basan en la posibilidad de equipar los nodos con características que los transforman en elementos activos. En el caso que nos atañe en este proyecto, conseguimos dar a ciertos nodos de la red (conmutadores activos) características activas mediante la implementación en ellos de agentes Conceptos fundamentales sobre agentes Este apartado no pretende ser un compendio acerca de los agentes: origenes, tipos... Sino que nos centramos en la definición estricta para la propuesta TAP. Nos encontramos ante un problema cuando intentamos definir un agente. Existen numerosas definiciones en la literatura, pero creemos que la más destacable puede ser: las redes de comunicaciones futuras se conciben más automatizadas, pudiendo ser gestionadas por entidades software, tanto móviles como estáticas, coleccionando información de estado de la red y que aportan la habilidad innata para invocar cambios efectivos en los controladores de los conmutadores sin la interacción explícita de ningún operador humano. Dentro de la definición de agente caben muchos tipos. Uno de ellos es el agente software. Es el tipo de agente más específico. Se puede definir como una entidad que puede interactuar con su entorno. Es decir, existen agentes que pueden ser implementados usando software, lo que significa que pueden ser autónomos y pueden reaccionar con otras entidades, incluyendo los humanos, máquinas y otros agentes software en varios entornos o plataformas. Debemos destacar que este planteamiento es el que nosotros usamos en nuestra propuesta de forma que nos referiremos a la arquitectura TAP como constituida por agentes software. 20

21 4.2. Sistemas multiagentes (SMA) La mayoría de los problemas se podrían solventar con un único agente, pero atendiendo a la programación descendente y modular, ese problema, puede dividirse en otros subproblemas cada vez más sencillos. Se huye de la idea del agente omnipotente. Se tiende a este planteamiento en el que múltiples agentes autónomos interactúan, se coordinan (cooperando, compitiendo o ambas cosas) y todo ello de una forma adaptativa. De esta forma se constituyen sociedades de agentes a las que se consideran Sistemas MultiAgentes (SMA). Motivos para emplear SMA: - El uso de un agente omnipotente puede darnos problemas en la escalabilidad y puede producir pérdida de eficiencia. La solución pasa por dividir el problema y por lo tanto el agente. - Si centramos todo el conocimiento sobre un agente pueden aparecer problemas como la falta de robustez del sistema, ya que un error en el conocimiento del agente es propagado a todo el sistema. - Distribuir la carga, las tareas o las funciones permite diseñar los agentes de un SMA como componentes autónomos que actúan en paralelo para resolver un problema de ámbito general. Los agentes pueden ser entes autónomos o formar parte de un SMA. Resulta relativamente sencillo extrapolar el concepto de agente hacia sistemas, poco o muy complejos, donde intervengan diversos agentes software coordinados entre sí y compartiendo informaciones que les sean de interés. De este modo podemos adquirir una idea clara e intuitiva de lo que sería un sistema o sociedad de agentes múltiples, distribuidos y cooperativos que interaccionan entre sí compartiendo información. 21

22 5. Arquitectura TAP 5.1. El SMA-TAP La arquitectura TAP está basada en la incorporación de varios agentes software en el modelo de conmutador propuesto y que hemos denominado AcTMs (conmutadores ATM activos). De este modo damos lugar a una red ATM activa en la que sus conmutadores van a desempeñar una función activa en la gestión de las colas de entrada, en la detección de congestiones, así como en la labor de retransmisiones cuando empiezan a perderse células de las fuentes de tráfico que se han elegido con tráfico garantizado. En la figura 5.1 vemos la posición que ocupa SMA-TAP dentro de la arquitectura ATM. SMA forma parte del Plano de Gestión ya que aporta nuevos mecanismos para la gestión de recursos ATM, siendo transparente a funciones como CAC y UPC. En esa misma figura también se muestra la extensión EAAL-5 que hemos desarrollado: Figura 5.1: Situación del SMA-TAP en el modelo arquitectónico ATM TAP centra sus objetivos en la consecución de la garantía de servicio, aunque es claro que este SMA puede ser fácilmente ampliado con nuevas funcionalidades más propias de la capa de control del modelo de referencia ATM 22

23 5.2. Arquitectura del SMA-TAP La arquitectura SMA-TAP es un sistema constituido por 5 agentes. En la figura 5.2 se puede observar esta arquitectura. Los distintos agentes software que componen la arquitectura SMA-TAP son: - Agente CoSA (Class of Service Agent): Agente programable que se encarga de recibir los parámetros del tráfico que proviene de las fuentes de entrada. Se encarga del establecimiento de la conexión, de las tablas de routing para determinar los VPI/VCI extremo a extremo y de la liberación de la conexión. - Agente WFQA (Weighted Fair Queuing Agent): Mantiene una coordinación constante con el agente CoSA. Recibe del CoSA los flujos de entrada destinadas a las colas que WFQA gestiona de forma justa y de acuerdo a los pesos establecidos en los parámetros del tráfico. - Agente programable CCA (Control Congestion Agent): Controla las congestiones basándose en EPDR y en otros algoritmos que el administrador de la red puede elegir. Este agente monitoriza el buffer de entrada, y cuando su ocupación sobrepasa el umbral establecido no acepta ninguna PDU entrante. - Agente RCA: Se encarga de generar células RM nativas que son transmitidas en sentido contrario al del flujo de la información. - Agente DPA: Se encarga de obtener las PDU o células del buffer de entrada cuando son transmisiones, o PDU de la DMTE cuando se trata de retransmisiones. Una vez recibidas, se encargará de despacharlas completas al correspondiente puerto de salida, previa actualización de la Tabla de Entrada/Salida de ese puerto. Con esta técnica se evitan las congestiones de los puertos de salida y también la mezcla de células pertenecientes a diferentes PDU o fuentes. 23

24 Figura 5.2 Arquitectura TAP con el subsiste ma SMA-TAP Desde el punto de vista funcional de los agentes disponemos de un agente programable, que puede actuar como agente inteligente y también como agente reactivo ante situaciones de congestión. El agente CCA no sólo permite al operador elegir el algoritmo y los parámetros del esquema de control de congestión, si no que se comporta reactivamente ante la aparición de congestiones, y proactivamente pudiendo actuar para evitar la aparición de congestiones ajustando el valor umbral del buffer. Por otro lado, WFQA es un agente colaborativo que recibe eventos desde los agentes CoSA y RCA para llevar a cabo sus acciones generando como salida células y/o PDU clasificadas de acuerdo a los pesos de sus fuentes. El agente CoSA, también programable y reactivo, responde ante el establecimiento de conexión de las fuentes, para lo que necesita coordinarse con otros agentes similares en conmutadores adyacentes. El agente RCA, también reactivo, es capaz de atender eventos provocados por situaciones de congestión en su propio conmutador y en otros conmutadores de la red. Este agente colabora también directamente con el agente WQFA y de forma indirecta con CCA. Por último, DPA es un agente autónomo que, mediante técnicas de control, se encarga de actualizar las estructuras de datos del sistema como las Tablas de E/S, la memoria DMTE y el buffer del conmutador. En la figura 5.3 se puede observar la distribución de los agentes en las capas de la arquitectura SMA-TAP. 24

25 Figura 5.3 Arquitectura SMA-TAP en capas Conmutadores AcTMs Existen en la literatura múltiples arquitecturas de conmutadores ATM, aunque la mayor parte de ellas se basan en el uso de una matriz de conmutación donde confluyen las células de las conexiones de entrada que son conmutadas (tras asignarles sus correspondientes valores VCI/VPI) a los puertos de salida. Sobre esta propuesta base de arquitectura se han realizado múltiples variaciones entre las que podemos situar TAP que, con la intención de solventar las problemáticas que ya conocemos, ha sido equipada con los módulos citados en el apartado anterior, los cuales van a ser seguidamente comentados en detalle Colas de entrada Los conmutadores que constituyen las redes ATM deben encargarse de mezclar los flujos de tráfico que provienen de fuentes diferentes y enrutarlos después hacia distintos destinos a través de paths de conmutación y enlaces de transmisión que las células de las diversas fuentes pueden compartir durante gran parte de su tránsito. Para que todo este proceso sea posible, los nodos de la red deben disponer de un almacenamiento temporal de las células en buffers de tamaño finito, de forma que el flujo de los datos en cada momento pueda hacer que el tamaño de estas colas de almacén temporal crezca y disminuya de forma dinámica. En realidad, este no es ningún mecanismo nuevo si lo comparamos con las redes de conmutación de paquetes clásicas, aunque lo realmente novedoso en el caso de ATM es la muy superior velocidad de conmutación (superiores a 622 Mbps en ATM frente a poco más de 256 Kbps en X.25). Estos requerimientos de elevada potencia de conmutación obligan a que cualquier propuesta que pueda hacerse para la labor de encolado del tráfico de entrada a los conmutadores deba ser optimizada en cuanto a los tiempos de acceso y de procesamiento. 25

26 Por tanto, las labores principales de los conmutadores de la red son las de ofrecer un almacén temporal de las células en tránsito hasta su destino (o al menos hasta el siguiente conmutador), reenrutar estas células desde este almacén al correspondiente puerto de salida del conmutador, y sobre todo, conseguirlo de la forma más eficiente y rápida posible, aunque en nuestro caso deseamos añadir una nueva prestación como la GoS para aportar esa fiabilidad que la red no aporta, pagando por ello un precio importante en prestaciones cuando el almacén temporal de las células experimenta las impredecibles congestiones. Veremos después que las técnicas de encolado en los nodos de la red juegan un papel fundamental en el diseño, operación y rendimiento de las redes ATM, por lo que existen una gran variedad de formas de solventarlo en los conmutadores, aunque los esquemas principales se dividen en tres categorías (representadas en la figura 5.4), que colocan las colas en los siguientes puntos de los conmutadores: - En la entrada del conmutador, que se corresponde con la opción a) de la figura 5.4 donde los buffers de células se sitúan a la entrada del conmutador. Si se emplean buffers FIFO, se producen colisiones cuando dos o más cabeceras de colas compiten simultáneamente por la misma salida, lo que provoca que una de las células pueda quedar bloqueada. Pero también quedan bloqueadas las células que siguen a la célula bloqueada, aunque no tengan la misma salida. Este tipo de desventaja puede solventarse con memoria RAM, aunque se requiere para ello un control de las colas más complejo. Sucesivamente se han ido proponiendo mejoras para este tipo de colas de entrada, y un ejemplo de ello es la propuesta que comentaremos con TAP. - En la salida del conmutador, que se corresponde con la opción b) de la figura 5.4, donde podemos observar que, en este caso, las colas de buffers se sitúan en los puertos de salida del conmutador. En este tipo, el elemento de conmutación consta de una matriz con buffers de salida y, sólo cuando la matriz opera a la misma velocidad que las líneas entrantes, se provocarán las colisiones; es decir, varias células compiten simultáneamente por el mismo puerto de salida. Este problema puede atacarse reduciendo el tiempo de acceso al buffer, o bajando la velocidad de la matriz de conmutación. En muchos casos el bloqueo interno se debe resolver con buffers adicionales. - En los puntos de cruce (crosspoints) de la matriz de conmutación de los conmutadores, como puede observarse en el caso c) de la figura 5.4. A este tipo de elementos de conmutación suele denominarse butterfly o encolado central, y se caracterizan porque los buffers sólo se colocan en los puntos de cruce de la matriz, con lo que se previene que las células que compiten por puertos diferentes no se afecten simultáneamente. Además, mediante un control lógico, puede elegirse qué buffer es el primero en el caso de que varias células o paquetes compitan por el mismo puerto de salida. La situación c) de los buffers en los crosspoints supone disponer de una cola en cada uno de los puntos del cruce de la matriz de conmutación, lo que implica que hay que dividir el espacio de buffer total de N 2 colas diferentes, cuando podrían ser N como ocurre en las otras dos opciones citadas. Esta división de recursos de almacenamiento puede acabar provocando un incremento de la probabilidad de pérdida de células al incrementar el número de colas potencialmente congestionables, además de aumentar considerablemente la labor de gestión de colas. 26

27 Figura 5.4 Alternativas para situar las colas en los conmutadores Tras largas investigaciones de los tres diseños, éstas se inclinan por el uso de colas de entradas. Como se ha explicado anteriormente, en este proyecto se ha optado por la solución de las colas de entradas. Al añadir diferentes pesos a las colas de entradas nos permite usar mecanismos justos para el tratamiento de las colas. A esta solución de colas de entrada, en nuestro proyecto, además, proponemos el uso de un buffer (figura 5.5) que es un punto donde se multiplexan las salidas de las colas. Es en este buffer donde se solventan las congestiones, que es el punto principal del uso de TAP. Figura 5.5 Esquema de bloques de la arquitectura de los conmutadores AcTMs 27

28 Las colas de entrada realizan un buffering de las células que llegan al conmutador activo. Cada cola realiza un tratamiento de dichas células en función de su VPI/VCI, intentando tratar de forma individualizada cada conexión. En el siguiente punto de este módulo expondremos el uso de mecanismos justos para el tratamiento de las colas. Estos mecanismos evitarán situaciones de inanición de las fuentes con menos requerimientos frente a aquellas que sean más ambiciosas. Veremos dos posibles soluciones: Fair Queueing y QPWFQ. 28

29 6. Gestión justa de colas En este apartado vamos a tratar el problema que surge cuando se producen situaciones de injusticia en la entrada de los conmutadores. Esta injusticia se produce cuando hay fuentes exigentes frente a que los son menos. Éstas últimas pueden caer en una situación de inanición. En el caso de nuestra simulación, debido a la existencias de fuentes privilegiadas de tráfico (mediante GoS), se hace necesario el uso de mecanismos de justicia. Una posible solución es emplear conmutadores que realicen asignaciones de ancho de banda justas, pero los algoritmos son demasiado complejos y esta complejidad puede llegar a hacer peligrar parámetros como del delay y jitter, de importancia crítica para conexiones de alta velocidad (p.ej. conexiones en tiempo real). Todos los planteamientos de arquitectura ATM cuentan con la inclusión de colas empleadas para aplicar la gestión del tráfico. En general, los conmutadores ATM enrutan las células desde un conjunto de puertos de entrada hasta un conjunto de puertos de salida basados en los identificadores de flujo VPI/VCI. En el puerto de salida de un conmutador ATM un controlador de puerto multiplexa células desde diferentes flujos de entrada en la línea de salida. Los puertos de salida de los conmutadores ATM son gobernados por una política de planificación como FIFO, que decide qué células desencolar de la cola de salida. Las políticas de planificación pueden ser clasificadas en work-conserving o non work-conserving. Una política es work conserving si nunca deja el enlace de salida en estado de inactividad mientras haya células dentro de la cola de salida. Al contrario, una política non work-conserving puede dejar el enlace de salida en estado de inactividad incluso si la cola de salida no está vacía. La siguiente tabla presenta la clasificación de algunas de las más conocidas políticas de planificación. Servicios work-conserving Weighted Fair Queuing Virtual Clock Delay Earliest-Due-Date Self-Clocked Fair Queuing Servicios non-work-conserving Jitter Earliest-Due-Date Stop-and-Go Hierarchical Round-Robin Todas las políticas work-conserving tienen, para un conjunto dado de patrón de llegada de células, idéntico retardo medio de células y necesidades máximas de buffer. Una política non work-conserving puede necesitar mayor retardo medio de células y necesidades de buffer máximo y medio que una política workconserving. Por otro lado, las políticas work-conserving tienden a incrementar las ráfagas de tráfico, mientras las políticas non work-conserving pueden ser usadas para limitar el tráfico a ráfagas. En líneas generales las políticas work-conserving son más fáciles de implementar y requieren una gestión de buffers más sencilla. Servicios work-conserving Idéntico retardo medio de células y necesidades máximas de buffers. Servicios non-work-conserving Puede requerir mayor retardo medio de células y necesidades máximas y medias de 29

30 Tienden a incrementar las ráfagas de tráfico. Fáciles de implementar. Envían los paquetes una vez que ha terminad o el servicio, no espera para servir el siguiente paquete. buffers. Pueden ser usadas para limitar el tráfico a ráfagas. No tan fáciles de implementar. Esperan un espacio de tiempo aleatorio antes de servir el siguiente paquete de una cola, incluso si hay paquetes esperando. Las se pueden gestionar de diferentes maneras que influyen de manera muy diferente en el tráfico y en los requisitos de los conmutadores Fair Queuing Los algoritmos Fair Queuing se diseñaron para que los conmutadores y routers ofrezcan el control de congestión y para la asignación justa de ancho de banda. Sin embargo, el coste de la implementación en una red completa puede ser prohibitivo para aplicaciones de alta velocidad, tanto por la complejidad en la programación como por la necesidad de que el algoritmo FQ mantenga información del estado, gestione los buffers de entrada, realice la planificación de paquetes... No obstante, varias investigaciones han demostrado que las propuestas de control de congestión extremoa-extremo pueden ser mejoradas de una forma sustancial si en los routers se aplican técnicas justas de asignación del ancho de banda disponible en la red ya que, además de proteger unas fuentes de otras, permiten que en la red puedan coexistir diversas políticas de control de congestión. Del mismo modo, varias de estas investigaciones también reconocen que la asignación justa de ancho de banda juega un papel necesario, aunque a veces no beneficioso, en el control de congestión. Así, la mayor parte de propuestas en este campo parten de dos premisas importantes, por un lado que los mecanismos justos de asignación de ancho de banda son necesarios, y por otro, que la complejidad de estos mecanismos es un importante factor para su adopción en las redes. Lo que parece claro es que cualquier propuesta que realicemos en este sentido será bastante más compleja de implementar que el clásico encolamiento FIFO que ha sido el más usado tradicionalmente. Como es sabido, en FIFO los paquetes son servidos en el orden de llegada, y los buffers son gestionados siguiendo una sencilla estrategia drop-tail según la cual los paquetes entrantes son tirados cuando el buffer está lleno. Pero FIFO carece de la justicia que se buscó con FQ y sus variantes y con mecanismos de abandono por flujos como FRED (Flow Random Early Drop). En cualquiera de estas técnicas se requiere mantener el estado de los diversos flujos por separado, de forma que, para cada paquete que llega, hay que clasificarlo en su correspondiente flujo, actualizar las variables de estado de cada flujo y realizar operaciones (encolar_paquete, tirar_paquete, priorizar_flujo, etc) en función del estado de cada flujo. RED (Random Early Detection) sirve también los paquetes en el orden de llegada, pero la gestión del buffer es mucho más sofisticada que el drop-tail de FIFO. RED tira probabilísticamente paquetes largos antes de que el buffer se llene, ofreciendo indicación de congestión rápida a los flujos que pueden ser afectados antes de que se produzca el rebosamiento 30

31 del buffer. De este modo RED mantiene dos umbrales en los buffers. Cuando la ocupación media del buffer es menor que el primer umbral, no se tira ningún paquete, pero cuando se supera el segundo umbral, los paquetes comienzan a ser tirados por la red. Cuando la ocupación del buffer se encuentra entre los dos umbrales, es cuando la probabilidad de tirar paquetes incrementa linealmente con la ocupación del buffer. FRED (Flow Random Early Drop) lo que hace es ampliar RED para ofrecer un cierto grado de asignación justa de ancho de banda. Para conseguir la justicia, FRED mantiene el estado de todos los flujos que tienen, como poco, un paquete en el buffer. Al contrario que en RED, donde la decisión de tirar paquetes se basa sólo en el estado del buffer, en FRED la decisión se basa también en el estado de los flujos. De este modo, FRED tira preferentemente los paquetes de un flujo al cual se le han tirado pocos paquetes anteriormente, y que poseen una cola mayor que el tamaño medio de las colas. Este algoritmo tiene dos variantes, que se diferencian en que una de las versiones garantiza a cada flujo un número mínimo de buffers. Todos los algoritmos comentados presentan diferentes niveles de complejidad. FRED se encarga de clasificar los flujos entrantes, mientras FIFO y RED no lo hacen. En suma, ninguno de ellos debe implementar ningún algoritmo de planificación de paquetes, sin embargo, todos aplican una sencilla planificación FIFO GPS, PGPS (WFQ) y PFQ La disciplina GPS (Generalized Processor Sharing) tiene 2 propiedades importantes: 1) Puede garantizar un servicio de retardo limitado extremo-a-extremo a una sesión cuyo tráfico está controlado por leaky bucket. (Bueno para tráfico best-effort y servicios jerárquicos de enlace compartido) 2) Puede asegurar asignación justa de ancho de banda a todas las sesiones que tienen trabajo en espera, estén o no sometidas al control de tráfico. (Base para aportar GoS al tráfico) GPS usa un modelo fluido ideal que no se puede implantar en el mundo real por lo que se han realizado aproximaciones a éste modelo. A estas aproximaciones se les denomina PGPS (Packet Generalized Processor Sharing) o, en otros casos, PQF (Packet Fair Queuing). El algoritmo (basado en GPS) más popular y más implantado es el WFQ (Weighted Fair Queuing), también conocido como PGPS. Existen importantes diferencias entre los servicios ofrecidos por el sistema de paquetes WFQ y el sistema fluido GPS. GPS es una disciplina de los servicios de los paquetes en los puntos de encolado de la red. GPS es una forma especial de procesador head-of-line compartiendo disciplinas de servicio PS (Processor Sharing). Con PS tenemos una cola FIFO separada para cada sesión que comparte el mismo enlace. Durante un intervalo de tiempo, cuando hay exactamente N colas no vacías cada una de ellas asociada a un servicio compartido, el servidor GPS sirve los N paquetes de las cabeceras de las colas simultáneamente, cada uno a una velocidad de N veces la velocidad del enlace. Mientras un servidor PS sirve todas las colas no vacías a la misma velocidad, GPS permite a diferentes sesiones tener diferentes servicios compartidos y sirve las colas no vacías en proporción al servicio compartido de las correspondientes sesiones. 31

32 Un servidos GPS, sirviendo N sesiones, se caracteriza por N números reales positivos φ 1, φ 2,..., φ N. Estos valores indican el tamaño relativo de servicio para cada sesión. El servidor trabaja a una velocidad fija r y es work-conserving. Hay que destacar que GPS es un servidor ideal que no transmite paquetes como entidades. Esto asume que el servidor puede servir todas las sesiones pendientes simultáneamente y que el tráfico es infinitamente divisible. En la realidad sólo una sesión puede recibir un servicio en un instante, y un paquete entero debe ser servido antes de servir otro. En la figura 6.1 se representa un diagrama de tiempos de la llegada y transferencia de paquetes pertenecientes a la sesión i en un sistema GPS. Figura 6.1 Diagrama de tiempos de llegada y salida de paquetes en la disciplina de servicio GPS Una de las líneas de trabajo de GPS está centrada en el diseño de algoritmos de control de congestión basados en realimentación para ser usados en redes de datagramas. Así, en este caso las fuentes muestrean constantemente el estado de la red para detectar síntomas de congestión y, cuando los detectan, las fuentes reducen la velocidad de envío para aliviar el efecto de la congestión. En el caso de que todas las fuentes empleen la misma cola FIFO para el envío de su tráfico, si una de las fuentes no reacciona al control de congestión, nos encontraremos con el hecho de que todas las sesiones acabarán sufriendo el problema de congestión. Para evitar este problema se propuso emplear una cola FIFO separada para cada sesión y atender las colas existentes en una política Round-Robin. Este esquema se comporta mejor que un FIFO puro, pero en el caso que existan fuentes con distintos tamaños de paquetes, puede ocurrir que las que generen paquetes más grandes acaben consiguiendo más ancho de banda que las que los generan más pequeños. Destacamos que la disciplina de servicio PS, descrita antes, este problema no aparece porque las sesiones en espera reciben el mismo ancho de banda independientemente del tamaño de los paquetes. El algoritmo GPS tiene por tanto una serie de interesantes propiedades para las redes de servicios integrados como ATM y, de hecho, se han propuesto muy diversos algoritmos PFQ (Packet Fair Queuing) para aproximar GPS a alas redes de conmutación de paquetes, aunque no demasiadas para las de tecnolgía ATM. El coste de implementación de los algoritmos PFQ está influido por dos aspectos: 1) Cálculo de la función de tiempo virtual del sistema que es una medida dinámica del tamaño de servicio justo normalizado que debe recibir cada sesión. La mayor parte de los algoritmos PFQ propuestos se mueven entre costes O(1) y O(logN) en cuanto a complejidad de la función de tiempo vitual. 32

33 2) El coste del mantenimiento del orden relativo de los paquetes a través de su marca de tiempos en un mecanismo basado en colas con prioridad desde donde se transfieren los paquetes. La complejidad algorítmica de implementación de una cola con prioridad para N números arbitrarios es O(logN). Pueden conseguirse menores costes, pero son de difícil implementación en redes de alta velocidad. Las colas con prioridad en PFQ pueden basarse en tiempo virtual de inicio, en el de finalización, o en ambos. Como cualquiera de estos tiempos crece monótamente con cada sesión, solo necesitamos considerar las cabeceras de cada sesión cuando el servidor está tomando el siguiente paquete a ser transferido. Así, el número de entidades en la cola con prioridad coincide con el número de sesiones activas. Existen bastantes aproximaciones de algoritmos PFQ que procesan paquetes basados en GPS, pero todos usan un mecanismo similar de colas con prioridad, basados en la noción de tiempo virtual. Las propuestas se diferencian en la elección de la función de tiempo virtual y en la selección de la política de paquetes. Para poder aproximarse a GPS, los algoritmos PFQ mantienen una función de tiempo virtual V(.), un tiempo de inicio virtual I i (.), y un tiempo de finalización virtual F i (.) para cada una de las i sesiones. En el caso de las redes ATM es lógico representar el tiempo virtual en términos de la cantidad de células servidas. En la mayor parte de los casos de PFQ, cuando el servidor está eligiendo el siguiente paquete para transmitir, los algoritmos optan, de entre todos los paquetes del sistema, por aquel que tenga el tiempo final virtual más pequeño, es decir, se aplica una política de selección de paquetes primero los tiempos virtuales más pequeños (SFF). Esta política de selección de paquetes suele dar lugar a límites de retardo casi idénticos a los del sistema fluido GPS, sin embargo, acaba dando lugar a mayores tiempos de servicio que GPS. Otra de las líneas más importantes de GPS está en la forma de ofrecer servicios con garantía de retardo limitado en redes de conmutación de paquetes. El esquema PGPS (Packet Generalized Processor Sharing), bajo el nombre de WFQ (Weighted Fair Queuing) es el algoritmo PFQ más conocido. La disciplina de servicio de PGPS se centra en el tratamiento igualitario de todos los usuarios y, a partir de estos planteamientos, han surgido posteriormente nuevas investigaciones que han dado lugar a variantes extendidas de PGPS. Aunque WFQ es el algoritmo más conocido y reconocido como mecanismo de planificación ideal en términos de sus propiedades combinadas de límite de retardo y proporcionalidad de justicia, varios trabajos demuestran que la complejidad asintótica del algoritmo crece linealmente con el número de sesiones atendidas por el planificador, lo que limita su uso en aplicaciones de elevada velocidad. De este modo, se proponen 2 algoritmos de complejidad constante O(1) en gestión de marcas de tiempos (pesos) y además, conservan los mismo valores de retardo extremo-a-extremo y tamaños de buffers de WFQ. El primer algoritmo FFQ (Frame-based Fair Queuing) emplea un mecanismo de tramas para recalibrar periódicamente una variable global rastreando la evolución de los trabajos en el sistema y limitando la injusticia en peridos cortos de tiempo determinados por el tiempo de las tramas. El segundo algoritmo SPFQ (Starting Potential-based Fair Queuing) realiza la recalibración en el límite de los paquetes. Aunque existen numerosas alternativas, este proyecto no abarca el estudio de éstos. 33

34 6.3. Propuesta QPWFQ para TAP Comparando las diferentes propuestas, podemos decir que WFQ, también denominado PGPS, aporta interesantes prestaciones en cuanto a retardo y justicia, sin embargo, su coste computacional y complejidad de implementación han impedido su implantación. Para este proyecto, hacemos uso del algoritmo QPWFQ (Queue PDU Wigthed Fair Queuing) inspirado en QLWFQ (que se explicará a continuación), para conseguir aportar un tratamiento justo a las PDU que llegan a los conmutadores AcTMs. Dado que debemos dar un tratamiento privilegiado a las PDU pertenecientes a las conexiones con GoS, el mecanismo de pesos de colas es de suma utilidad para nosotros. Además, nos encontramos con otra particularidad no tratada por ninguno de los algoritmos estudiados que es el hecho de tener que dar respuesta a las retransmisiones de PDUs congestionadas. Esto nos va a determinar el tener que incluir en el algoritmo QPWFQ un tratamiento prioritario para las retransmisiones QLWFQ La literatura presenta diversas variantes mejoradas sobre las propuestas anteriores. Para nuestro proyecto queremos centrarnos en una de estas propuesta, QLWFQ (Queue Length based WFQ), que es un algoritmo work-conserving de coste constante O(1) para la planificación de colas per-vc en redes de conmutación de paquetes de longitud fija como ATM. QLWFQ es compatible con FQ y FIFO y se basa en la asignación de pesos a las colas y en el establecimiento de créditos para determinar el orden de atención de las células ATM en función de la comparación de la longitud de cada cola con su peso particular. El algoritmo compara, a la llegada y partida de las células, la longitud de las colas con los pesos que cada una tiene asignados. QLWFQ es en realidad una simplificación de WRR (Weighted Round Robin) consiguiendo un mejor equilibrio entre aislamiento de tráfico y compartición de recursos que los algoritmos basados en marcas de tiempos QPWFQ A continuación vamos a describir el funcionamiento general del algoritmo QPWFQ y, a un tiempo, comentaremos el mecanismo aplicado a las colas de entrada de los conmutadores AcTMs para demostrar justicia del mismo, así como su sencillez de implementación que acaba resultando en un constante O(1). Igualmente, veremos que QPWFQ procesa, tanto células como PDUs, y describiremos la sencilla técnica usada para mantener las características work conserving de WFQ, así como la posibilidad de tratamiento prioritario de las solicitudes de retransmisiones de PDUs pertenecientes a las conexiones garantizadas. Como puede observarse en la figura 6.2, tenemos 3 colas de espera, cada una de ellas con su correspondiente peso p. En nuestro caso la Cola 1 tiene peso 3, la cola 2 peso 2 y la Cola 3 peso 1. Las posiciones de cada cola pueden almacenar, tanto PDU como células para ser procesadas hasta el buffer del conmutador. Cuando una PDU, o una célula, llega a una cola, la 34

35 longitud l de esta cola es incrementada en una unidad y es introducido el número de cola en la cola de turnos siempre que l<=p. Cuando la cabecera de una cola de espera es servida, la longitud de esta cola es decrementada en una unidad y se comprueba si l>=p para seguir atendiéndola, siempre y cuando en las restantes colas no se cumpla l<=p. De este modo se garantiza la característica workconserving (el servicio no se detiene mientras exista tráfico que procesar), que permite atender colas con tráfico continuado siempre y cuando en las restantes tráficos no exista tráfico. En la figura 6.2 se supone que en el instante 0 en la cola 1 había una PDU, la cola 2 estaba vacía y en la cola 3 existía otra PDU. Así, la longitud de la cola 1 se incrementa en una unidad, y en la cola de turnos se ha insertado el crédito 1 (suponiendo que atendemos las colas circularmente y de forma ascendente) ya que su peso es 3 y la longitud de la cola en ese instante es 1 (l<=p). Posteriormente es tratada la cola 3, su longitud es incrementada en 1, y se anota su turno en la cola de turnos ya que su peso es 1, lo mismo que su longitud (l<=p).si suponemos mantenernos en esta situación sin servir las cabeceras de las colas 1 y 3 a la salida, y en ese momento llegan tres nuevas unidades a la cola 1, éstas serán atendidas de forma continuada por la característica work-conserving, ya que a las colas 2 y 3 no llega tráfico. De este modo se atienden dos nuevas entradas de la cola 1 pero al ser atendida la tercera llega una célula a la cola 2 que pone su longitud a 1 y es pasado su turno a la cola de turnos ya que l=1 <= p=2. Ahora veremos cómo es el procedimiento de salida de las células o PDUs de las colas de entrada?. En la cabecera de la cola de turnos hay una indicación acerca de la cola que debe ser tratada en cada momento. Según la figura 6.2 la cola que hay que atender es la 1 (según la cola de turnos). Al tratar la cola 1, se envía su cabecera al buffer y se decrementa la longitud de esta cola en una unidad. A continuación se eliminan las cabeceras de la cola de turnos y de la cola 1 y se procede a calcular primero si l<=p y después si l>=p. En la figura de ejemplo (figura 6.2) se supone que no llegan PDUs pertenecientes a retransmisiones de conexiones privilegiadas. Si ocurriese la llegada de una PDU de este tipo, el agente WFQA le daría un tratamiento prioritario. 35

36 Figura 6.2 Esquema de planifiación del algoritmo QPWFQ. El WFQA tendrá conocimiento de la inminente llegada de una PDU retransmitida a través de la comunicación del agente RCA que le indica el índice VPI/VCI/PDUid/Port. Esta comunicación activa una nueva variable asociada a cada cola para saber que va a llegar una retransmisión. Cuando llega la PDU es introducida en su correspondiente cola y es apuntada para garantizar el acceso directo. De este modo, las colas de espera pueden servir células y PDU, no sólo desde las cabeceras, sino también desde los punteros que identifican las PDU retransmitidas. Así, las colas FIFO, implementadas con punteros, permitirán priorizar las PDU retransmitidas que, a medida que van llegando, son insertadas, no al final de las colas, sino al principio de las mismas con la intención de garantizar el coste constante. Para realizar las priorizaciones, se debe realizar también un tratamiento sobre la cola de turnos, ya que, se debe insertar en su cabecera la indicación de la cola con la PDU que es retransmisión de una conexión privilegiada. Aunque las colas pueden contener células nativas ATM y PDU privilegiadas y, aparentemente esto puede conducir a situaciones injustas en las células respecto a las PDU, la estrategia aplicada, basada en los pesos y las longitudes de las colas, permite que no se produzcan situaciones de inanición de paquetes pequeños respecto a los de mayor tamaño. 36

37 7. Mecanismos de control de congestión Los esquemas de control de congestión más conocidos son RCD (Random Cell Discard), PPD (Partial Packet iscard) y EPD (Early Packet Discard). Avanzamos ya que el esquema EPD se ha demostrado como una solución interesante para conseguir óptimo funcionamiento desde el punto de vista de la justicia y utilización de los enlaces. Sin embargo, existen otros esquemas con idénticos objetivos que son maximizar el throughput y la justicia, mientras se minimiza el retardo en las redes ATM. Algunos de estos mecanismos son: ESPD (Early Selective Packet Discard), FBA (Fair Buffer Allocation) y RED (Random Early Detection). Para TAP, se ha introducido y modificado una variación de EPD en TAP de forma que, cuando una de las PDU llega al buffer, esperamos a la célula final de cada PDU para aplicar EPD en los conmutadores AcTMs, desechando aquellas PDU que provoquen congestión en el buffer y solicitando su retransmisión mediante NACKs al conmutador previo. Las PDU que no provocan congestión en el buffer son enviadas a los puertos de salida de forma completa aplicando VC merge para aliviar también los problemas de interleaving. Cuando se llena el buffer de un conmutador congestionado, las células que llegan serán descartadas y, con una elevada probabilidad, muchos paquetes perderán células y mientras otras células seguirán su transmisión a través de la red, provocando el indeseable fenómeno que de la fragmentación de paquetes. Al evitar la fragmentación estamos optimizando el ancho de banda de los enlaces de la red que no se ven sobrecargados con las retransmisiones extremo-extremo, ni con la transmisión de PDU completas que pueden estar corruptas por la pérdida de una sola de sus células. En esta sección del proyecto explicaremos el mecanismo EPD para, a continuación, explicar la modificación que se ha implantado, basado en EPD (EPDR) Antecedentes, mecanismo EPD El mecanismo EPD (Early Packet Discard), es una técnica de gestión de buffers implementada para asegurar un elevado throughput extremo a extremo. Este mecanismo realiza descartes de paquetes completos, en lugar de descartes parciales como hacen otros. EPD tirará los paquetes completos antes de que el buffer acabe llenándose, con la intención de que los paquetes que puedan ser susceptibles de perder alguna célula, y por tanto su integridad, no sean transmitidos por la red. Con EPD, en lugar de tirar células (o PDUs) de varias conexiones cuando el buffer se llena, este mecanismo opta por tirar una PDU completa antes de llenar el buffer. De este modo, también se evita fragmentación y se evita que paquetes corruptos se transmitan. 37

38 Veremos ahora la simplicidad de este algoritmo para comprobar que su implementación es perfectamente asumible desde el punto de vista de la justicia y el goodput conseguidos. Para poder aplicar EPD, en los conmutadores, hay que establecer un umbral en los buffers a fin de marcar el llenado del buffer. Cuando este umbral es alcanzado, no se admitirá la entrada de más paquetes. Es decir, cuando llega la primera célula de un paquete a un buffer que está lleno hasta, o por encima de, su valor umbral, esa célula es desechada, y también todas las demás células pertenecientes a ese paquete, aunque la cola descienda inmediatamente su nivel de llenado por debajo del umbral. Por otro lado, las células de un paquete cuya primera célula llegó antes de que el buffer alcanzase el umbral no serán tiradas a no ser que el buffer acabe llenándose. En suma, cuando la primera célula de un paquete llega en un margen de llenado elevado del buffer, es descartada junto a todas las demás que pertenecen a su mismo paquete, ante el riesgo de provocarse la fragmentación del paquete. Lo importante de este método es escoger el valor del umbral para evitar el llenado del buffer con el consiguiente problema de fragmentación. Pero, además de la fragmentación, debemos encontrar el equilibrio que también evite el exceso de descartes de células y, por lo tanto, el número de retransmisiones. Entonces, si el umbral es demasiado alto, este mecanismo no servirá para nada y si es excesivamente bajo se tirarán un número excesivo de paquetes. En las siguientes figuras, se puede observar el funcionamiento de este mecanismo. TAC=Tamaño_actual_de_la_cola CMB=Capacidad_máxima_del_buffer_del_conmutador Mientras una célula está llegando a un conmutador; Si la célula es la primera célula de un paquete Si TAC >= Umbral En otro caso Aceptar la célula en cola FIFO FinSi En otro caso Si ya se ha tirado alguna célula de este paquete Tirar la célula En otro caso Si TAC >= CMB Tirar la célula En otro caso Aceptar la célula en cola FIFO FinSi FinSi FinSi FinMientras Figura 7.1 Algoritmo EPD 38

39 Figura 7.2 Representación gráfica de EPD procesando PDUs AAL-5 El algoritmo EPD puede tener otros planteamientos o versiones, pero el problema general es el mismo. Una de estas versiones es la que aplicamos en este proyecto, el mecanismo EPDR Propuesta EPDR En este proyecto el esquema de control de buffer que empleamos es un mecanismo basado en EPD. Este mecanismo recibe el nombre de Early PDU Discard and Relay (EPDR). Este mecanismo: Incluye un mecanismo de retransmisión cuando se detectan PDU que van a provocar desbordamiento del buffer. Cuando se detecta el llenado del buffer, comienza el descarte de células y, automáticamente se solicita una retransmisión al conmutador previo. Esta propuesta permite la retransmisión de forma local, evitando retransmisiones extremo a extremo, y así, mejorando el goodput. Las retransmisiones sólo se solicitan en el caso que la fuente tenga suficiente tiempo de inactividad para atenderlas sin afectar a la transmisión en curso. Esta propuesta ahorra, en el peor de los casos, el tiempo RTT extremo a extremo (y ahorra el proceso de solicitud de retransmisión de protocolos superiores como TCP). Y lo que es más importante, la implosión en los emisores de tráfico es solventada por la delegación realizada en los conmutadores AcTMs que soportan la arquitectura TAP. El problema de la fragmentación de PDUs se solventa empleando el campo EOM de las tramas EAAL-5, que es, otra propuesta de este proyecto. 39

40 El buffer es controlado por un agente programable que permite la coordinación con otros agentes del sistema para ajustar los umbrales más convenientemente en función del estado del conmutador. El coste algorítmico es similar a otros esquemas de este tipo. Los requisitos hardware para su implementación no son extraordinarios. En la figura 7.3 se muestra el algoritmo EPDR. Se puede observar la introducción (respecto al algoritmo EPD) de una llamada a la función Retransmitir (indexpdu). El umbral lo determina el agente CCA aunque, en la implementación del simulador, este valor se introduce manualmente. Como podemos comprobar en el algoritmo, en cuanto la longitud actual de la cola iguala el valor del umbral, el conmutador se dispondrá a tirar todas las células de la PDU que ha provocado la situación. Cuando llega la primera célula de una PDU y ya se ha igualado el umbral, se tira esa célula y se marca el VPI/VCI de la célula en la lista-descartes para, a continuación, tirar todas las células de esa misma PDU hasta llegar a su última célula (EOM). Este es el modo en que se garantiza que no se produzca la fragmentación de la PDU, impidiendo que no se envíe ninguna célula de una PDU que ha provocado una situación de congestión. Una vez ha llegado la última célula de la PDU congestionada, y puede accederse al campo PDUid, se solicita la retransmisión de la PDU a través del agente RCA. Una vez solicitada la retransmisión de la PDU se procede a eliminar el valor VPI/VCI de la lista-descartes para que la siguiente PDU de esa misa conexión pueda ser aceptada en el buffer si ya ha pasado la situación de congestión. La célula EOM de la trama descartada se introduce en el buffer (si hay espacio), ya que esta célula, la emplea EAAL-5 para delimitar las diferentes PDUs. Con esta célula EOM se sabe cuando acaba una trama descartada. Este mecanismo, al igual que el EPD, no evita la fragmentación una vez que las células iniciales han entrado en el buffer y éste se ha llenado. Y, como ocurría en el algoritmo EPD, la fragmentación depende del valor del umbral establecido en el buffer del conmutador. Este valor del umbral debería ser unas 3 o 4 veces menor que el tamaño medio de una PDU. Aunque las células iniciales hayan podido entrar en el buffer, el resto de células serán automáticamente descartadas al saber que la trama está corrompida. Mientras una célula llega al buffer Si el VPI/VCI de la célula pertenece a la lista-descartes Si la célula es una célula EOM Si Longitud_de_Cola < Tamaño_Buffer insertar la célula en el buffer En otro caso tirar la célula FinSi Retransmitir(indexPDU) borrar el VPI/VCI de la lista-descartes FinSi En otro caso tirar la célula FinSi En otro caso Si Longitud_de_Cola < umbral insertar la célula en el buffer 40

41 FinSi FinMientras En otro caso Si (primera célula de PDU o (el buffer está lleno)) tirar la célula capturar el VPI/VCI en la lista-descartes FinSi En otro caso insertar la célula en el buffer FinSi Figura 7.3 Esquema de planificación del algoritmo EPDR En la figura 7.4 se representa el funcionamiento del EPDR. Podemos observar el punto de llegada del tráfico de entrada, así como los límites de los valores de la Conexión actual de cola (LAC), el valor umbral (U), y el valor de tamaño máximo del buffer (TMB). También se muestra la conexión existente entre el buffer y el agente WFQA, CCA, RCA y DPA, así como la conexión del buffer con la memoria DMTE en la que se realizan las copias de las PDUs que han llegado completas al buffer. Figura 7.4 Esquema gráfico del buffer 41

42 BASES DE LA SIMULACIÓN 8. Introducción En este módulo se expone un estudio de los mecanismos y procesos que intervienen en las redes ATM reales. Esto es necesario ya que, como es natural, hay que conocer profundamente la realidad que se pretende simular antes de intentar simularla. En nuestro caso, nuestro proyecto se centrará en conseguir un tráfico lo suficientemente real como para poder estudiar las ventajas de la implantación de TAP en las redes ATM. Por ello habrá ciertos aspectos de ATM que no serán necesario simular, ya sea porque no intervienen en TAP o porque su inclusión oscurecería el análisis de los resultados obtenidos. En este módulo, por tanto, procuraremos explicar qué está simulado, qué está simplificado, qué ha cambiado y qué se ha omitido y qué se ha añadido en nuestro simulador con respecto a una red ATM real. 9. Funciones y algoritmos de gestión de conexiones 9.1. Funciones y algoritmos de gestión de conexiones en las redes ATM reales. En esta sección vamos a describir primeramente el proceso real en las redes ATM mediante el cual se negocian, establecen y liberan las conexiones en las interfaces UNI y NNI. Posteriormente presentaremos el método de establecimiento de conexiones en nuestro simulador junto con aquellas estructuras y mensajes (tablas de enrutamiento, mensajes de establecimiento/cierre de la conexión, etc.) que serán utilizados Señalización Como ATM es un servicio orientado a conexión se necesitan protocolos específicos de señalización, estructuras de enrutamiento así como protocolos que encaminen las peticiones de conexión ATM a través de la red ATM. Las siguientes secciones describen el papel de la señalización en una red ATM. Como comentamos en el módulo I, los servicios orientados a la conexión de ATM se implementan usando conexiones virtuales permanentes (PVCs) o conexiones virtuales conmutadas (SVCs). En el caso de las PVC, el valor del par VPI/VCI en cada punto de 42

43 conmutación de la conexión se debe configurar manualmente y permanece activo de manera permanente. Debido a que estos circuitos requieren una labor intensiva de configuración no son muy escalables y no son una buena solución para las conexiones poco frecuentes o de corta duración. Los SVCs son la solución para los requerimientos de las conexiones bajo demanda. Son establecidos cuando son necesarios y desactivados cuando ya no lo son, liberando así ancho de banda en la red. Para lograr esta conducta dinámica los SVCs usan señalización: Para que dos elementos finales obtengan una conexión es necesario que ambas sigan un criterio común, esto es, dispongan de un protocolo de señalización común. En los SVC el sistema de señalización de ATM se encarga de encontrar la ruta adecuada desde el host origen al host destino a lo largo de varios switches. El host remoto debe aceptar el establecimiento de la conexión. Además de los PVCs y los SVCs hay un tercer tipo híbrido de ambos llamado PVCs ligeros. Estas conexiones son permanentes pero, como son establecidas mediante señalización, pueden ser configuradas fácilmente y re-enrutadas automáticamente si falla uno de los enlaces que la componen Establecimiento de la conexión y señalización Hay varias maneras de establecer una conexión. La normal es adquirir primero un circuito virtual con el conmutador inmediatamente adyacente para la señalización, y usarlo. Para establecer tal circuito, como veremos más adelante según la interface UNI, las células que contienen una solicitud se envían por el VPI 0/VCI 5. Si hay éxito, se abre un circuito virtual nuevo por el se pueden enviar y recibir solicitudes y respuestas de establecimiento de conexión. En la figura a se muestra cómo el router A (origen) establece una comunicación con el router B (destino) usando señalización con un circuito virtual ya previamente establecido para este propósito. Figura 9.1 Ejemplo de conexión Los pasos del proceso son los siguientes: 1- El Router A envía un paquete con un mensaje SETUP al conmutador directamente conectado a él (conmutador ATM 1). Esta petición contiene la dirección ATM de ambos extremos origen y destino así como las características demandadas para la conexión. 2- El conmutador ATM 1 reensambla el paquete del router A y lo examina. Responde al Router A con un mensaje de establecimiento. 3- Si el conmutador ATM 1 tiene una entrada para el router B en su tabla de conmutación y 43

44 puede acomodar la QoS demandada por la conexión, entonces reserva recursos para la conexión virtual y reenvía la petición hacia el siguiente conmutador (conmutador ATM 2) a través de una trayectoria dada. 4- Cada conmutador a lo largo del camino hacia el router B reensambla y examina el paquete de señalización y posteriormente lo reenvía al siguiente conmutador tan sólo si puede soportar los parámetros de tráfico en las interfaces de entrada y de salida. A medida que el mensaje de establecimiento se propaga hacia el destino, es reconocido en cada salto por un mensaje de llamada en proceso. Cuando ser remite el paquete cada conmutador establece también las conexiones virtuales. Si cualquier conmutador a lo largo de la trayectoria no puede satisfacer las demandas de tráfico la petición se rechaza y se envía de vuelta al router A un mensaje de conexión rechazada. 5- Cuando el paquete de señalización legua al router B, éste lo reensambla y evalúa. Si puede soportar las demandas entonces responde con el mensaje de aceptación de conexión que será respondido por cada elemento por el que pase por uno de conexión reconocida. Cuando el mensaje de aceptación llega de vuelta al router A se completa la conexión virtual. Posteriormente los datos serán transmitidos a lo largo del mismo camino por el que ha discurrido la señalización. Cuando llega el momento de cortar la conexión se utiliza otra secuencia de señalización: 1- La parte que desea cortar envía un mensaje de liberación a la red ATM 2- En cada salto a lo largo del camino se reconoce el mensaje con uno de liberación completada. 3- La red ATM propaga el mensaje de liberación al otro extremo y termina el proceso de liberación; la conexión se considera así liberada. Protocolos de Señalización ATM--- UNI y NNI Los protocolos de señalización varían dependiendo de la interface de red ATM: Señalización en el Interface Usuario-Red (UNI): Se usa entre los sistemas finales y los conmutadores ATM a través de enlaces UNI. También puede usarse entre dos conmutadores ATM. Señalización en el Interface Red-Red (NNI): Se usa entre conmutadores ATM mediante enlaces NNI. La señalización UNI en ATM define el protocolo mediante el cual los SVCs se establecen dinámicamente entre los dispositivos ATM de la red. La señalización NNI es parte de la especificación PNNI que incluye además un protocolo de enrutamiento propio. EL ATM Forum tiene la tarea de estandarizar los procedimientos de señalización. Las especificaciones para UNI del ATM Forum están basadas en el protocolo llamado Q.2931 del ITU-T. Este protocolo especifica un formato para los mensajes de control de llamada que contiene información como el tipo de mensaje (establecimiento, liberación y otros) y más elementos de información como el formato de enrutamiento y la QoS. Las especificaciones UNI están agrupadas de la siguiente forma: UNI 3.x -- Consistente en dos conjuntos de especificaciones interoperativas, la UNI 3.0 y la UNI 3.1. UNI Incluye las especificaciones UNI 3.x y añade algunas características no soportadas 44

45 por aquella. Entre estas características destacan la señalización para conexiones ABR y el PNNI que especifica los protocolos de enrutamiento y señalización a través del NNI. Los mensajes de control más significativos especificados en la UNI 3.1 son los siguientes: Para conexiones p-p - SETUP: petición de establecimiento de circuito. - CALL PROCEEDING: respuesta a la anterior. - CONECT: aceptación de conexión. - CONNECT ACKNOWLEDGE: confirmación de la anterior. - RELEASE: petición de liberación de la conexión. - RELEASE COMPLETE: aceptación de la anterior. Para conexiones p-mp - ADD PARTY: añade un destino a la conexión. - ADD PARTY ACKNOWLEDGE: confirmación de la anterior. - ADD PARTY REJECT: rechazo. - DROP PARY: elimina un destino de la conexión. - ADD PARTY ACKNOWLEDGE: confirmación de la anterior. Todos estos mensajes los construye la capa AAL y como media cada uno de ellos se descompondrá en al rededor de 30 células Direccionamiento Las direcciones ATM son necesarias para los propósitos de la señalización cuando se establecen conexiones conmutadas. Existen tres formatos de direcciones ATM diferentes dependiendo del estándar de enrutamiento utilizado (OSI, CCITT). Sin embargo este aspecto (el formato y distribución de las direcciones) queda fuera del ámbito de nuestro simulador ya que no aporta nada a su propósito principal, es de comprobar las características de funcionamiento de la arquitectura TAP. Como veremos posteriormente, el protocolo que hemos elegido para el enrutamiento no necesita de direccionamientos jerárquicos lo que también justifica en cierta medida nuestra decisión Enrutamiento Existen dos protocolos de enrutamiento ATM: el "Interim Interswitch Signaling Protocol" (IISP) y el "Private Network-Node Interface" (PNNI). IISP proporciona soluciones de enrutamiento estático no fácilmente escalables y no aporta soporte para calidad de servicio (QoS). PNNI proporciona una solución de enrutamiento escalable que determina dinámicamente los caminos de enrutamiento y además soporta los requerimientos de QoS. 45

46 Enrutamiento estático con IISP Como su propio nombre indica, el "Protocolo Interino de Señalización entre Conmutadores" (IISP) es un protocolo de señalización para comunicaciones entre conmutadores. IISP fue una medida temporal diseñada para permitir interconexión entre conmutadores usando señalización basada en UNI hasta que la implementación del NNI, en la que está basada el protocolo PNNI, estuviera finalizada. Aunque menos poderoso y complejo que PNNI, IISP todavía se usa hoy en día para permitir la compatibilidad con conmutadores primitivos que no soportaban el protocolo PNNI. IISP también puede ser usado para aislar la distribución de información PNNI en situaciones de diseño de red específicas. Para permitir la señalización UNI, los conmutadores arbitrariamente toman el papel de usuario (U) o red (N) en cada extremo de un enlace IISP. Las peticiones de señalización son encaminadas entre conmutadores usando tablas de enrutamiento preconfiguradas en cada conmutador. Estas tablas se configuran con las direcciones de los elementos a los que se puede acceder a través de cada puerto del conmutador. Cuando un conmutador recibe una petición de señalización, éste comprueba la dirección ATM destinataria en su tabla y obtiene el puerto por el que deberá salir esta petición. Posteriormente redirige la petición de señalización a través del puerto obtenido usando los procedimientos UNI. El enrutamiento usando IISP requiere configuración manual de las tablas de enrutamiento. Para un número pequeño de caminos posibles es una tarea relativamente simple, pero en grandes redes la configuración requiere mucho tiempo y es propicia a errores. Ventajas: Algunas de las ventajas ofrecidas por IISP son las siguientes: Simple de configurar y de encontrar errores en redes pequeñas. Soportado por una la mayoría de los proveedores Puede usarse para conectar redes privadas ejecutando diferentes implementaciones propietarias del PNNI Inconvenientes Las limitaciones potenciales del IISP son las siguientes: Configuración estática de enrutamientos. No muy escalable debido a la configuración manual de las tablas de enrutamiento. El cálculo de la ruta debe hacerse salto a salto. Cada conmutador debe elegir la el puerto de salida para cada mensaje. Soporte limitado para QoS. No hay redireccionamiento "crankback" en caso de errores en la red. Sin embargo se pueden configurar trayectorias redundantes. 46

47 Señalización y enrutamiento PNNI El protocolo PNNI provee de mecanismos escalables de enrutamiento basados en la QoS de ATM y VCCs conmutador-a-conmutador interoperables. Para conseguir esto la especificación PNNI actúa en dos vertientes, señalización y enrutamiento Rasgos de la señalización PNNI La señalización PNNI es una extensión de la señalización UNI para su uso en enlaces NNI. La peticiones de señalización UNI, transportadas en el mismo canal virtual (VCI = 5), son mapeadas en señalización NNI en el primer conmutador origen de una comunicación. La señalización NNI es remapeada de nuevo a señalización UNI en el último conmutador destino. Entre los rasgos característicos de la señalización PNNI se encuentran los siguientes: soporta UNI 3.1-incluyendo conexiones p-p y p-mp soporta UNI 4.0-con las siguientes capacidades: parámetros individuales de QoS señalización ABR Negociación de parámetros de tráfico CoS ATM anycast Rasgos del enrutamiento PNNI El componente de enrutamiento del protocolo PNNI especifica cómo las peticiones de señalización y sus subsecuentes conexiones de datos se enrutan a través de una red ATM. Entre los rasgos característicos del enrutamiento PNNI se encuentran los siguientes: Protocolo con conocimiento de la topología mediante mensajes intercambiados por los elementos de la red a través de mecanismos de inundación. Configuración automática. Encaminamiento dinámico. Reacciona al estado de la topología. "Source routing". El conmutador ATM origen de una comunicación calcula por completo la ruta en el establecimiento de conexiones a partir de su conocimiento de la topología actual. Esta ruta la comunica a los demás conmutadores de la trayectoria elegida incluyéndola en el mensaje de establecimiento por lo que éstos no deberán recalcularse. Selección de la ruta que satisfaga los parámetros de QoS requeridos por la conexión. Soporta redes PNNI jerárquicas. Soporta "crankback". 47

48 CAC Connection Admission Control Hasta este momento hemos visto cuál es el proceso de establecimiento de una conexión, los mensajes se intercambian los elementos que intervienen en el este proceso y las diversas formas de elección de la ruta para dicha conexión. Sin embargo aún no hemos expuesto qué mecanismo es el que se encarga de aceptar o rechazar una nueva conexión. Este mecanismo es el CAC "connection admission control". Por lo tanto la función del CAC es la de decidir si podemos incluir una nueva conexión sobre la base de los recursos que demanda el usuario y los que tenemos disponibles. Se utiliza, pues, como mecanismo preventivo de control de congestión. El CAC se halla implementado en los nodos de conmutación de la red ATM. Como hemos descrito anteriormente, cuando un terminal m1 empieza una conexión contra otro terminal m2, m1 debe enviar un pedido de conexión (ESTABLECIMIENTO), al controlador de tráfico del nodo ATM. El pedido de conexión indicará información tal como el ID del destino, el QoS requerido y los parámetros de tráfico que definen las características de generación de la conexión. El nodo ATM estima el QoS de los parámetros de tráfico y permite que m1 establezca la conexión sólo cuando esta nueva conexión no degrade el QoS de ningún terminal. Los algoritmos que realizan el control de admisión no están especificados en ningún estándar. En lugar de ello se deja al fabricante implementar el mecanismo que crea oportuno de acuerdo con el producto que quiera ofrecer. A continuación mencionaremos una clasificación de tipos de algoritmos CAC creados hasta el momento Asignación no estadística Peak Bandwidth Allocation En este tipo de algoritmos la nueva conexión se acepta si la suma de todas las tasas de pico más la tasa de pico de la nueva conexión es menor que la capacidad del enlace. Es fácil de implementar, solamente necesitaremos conocer la tasa de pico de la nueva conexión. Sin embargo, debido a que el tráfico generalmente se genera a ráfagas, los puertos de salida estarán infrautilizados Asignación estadística Asignamos una capacidad por fuente inferior a la tasa de pico. La suma de todas las tasas de pico puede ser superior a la capacidad de la fuente. Para ello necesitamos conocer el régimen de llegadas de las fuentes. Es computacionalemente costoso pero sin embargo hace buen uso de los puertos de salida Basado en medidas Realiza una monitorización de los flujos tomando cierta cantidad de medidas como la tasa de pico, utilización o el tamaño de ráfaga. Estima el CLR o el ancho de banda efectivo en función de descriptores de tráfico y las medidas tomadas. 48

49 Tablas de enrutamiento de VCCs Los diseñadores de ATM quisieron evitar dedicar demasiado tiempo de cómputo en los conmutadores a determinar la manera de obtener la línea de salida para una célula a partir de su información de circuito virtual. Por ello diseñaron la capa ATM para hacer posible un enrutamiento eficiente. En la capa ATM los conmutadores, para enrutar eficientemente las células de datos que llegan a un conmutador hacia el puerto de salida adecuado, almacena unas tablas internas de enrutamiento llamadas tablas VCCs. Estas tablas se rellenan para cada conexión en el momento en el que ésta se establece. Posteriormente, durante el tiempo que dure el circuito virtual, cada conmutador enviará las células siempre por el mismo camino usando la tabla VCCs. No se puede asignar dentro de un mismo conmutador el mismo par VCI/VCI a dos conexiones activas en un mismo instante. Esta forma de enrutamiento se diferencia de la usada por los conmutadores de paquetes en que en aquellos la ruta de destino se calcula individualmente para cada paquete, de este modo la ruta a seguir podría cambiar entre un paquete y el siguiente. Por contra, en la conmutación de células, cada una de las células pertenecientes a una misma conexión siguen todas la misma ruta. Una tabla VCC en un conmutador podría presentar la siguiente forma: DESDE HACIA Puerto VPI VCI Puerto VPI VCI * 2 7 * Tabla 9.1: Tabla VCC genérica. Según esta tabla de ejemplo, todo tráfico que llegue al conmutador por el enlace 5 con VPI = 33 y VCI = 7 serán dirigidas al enlace 3 con VPI = 3 y VCI = 1. Si queremos que el conmutador soporte conexiones p-mp será necesario que para cada terna Puerto/VPI/VCI pueda haber más de una terna de destino. Por ejemplo: 49

50 DESDE HACIA Puerto VPI VCI Puerto VPI VCI * 2 7 * Tabla 9.2: TablaVCC genérica con conexiones p-mp Como hemos visto en este ejemplo el conmutador cambia los valores de VPI y VCI de salida con respecto a los de entrada. Los conmutadores que cambian ambos valores se denominan conmutadores VC en contraposición a los conmutadores VP que tan solo modifican el valor de VPI dejando el VCI intacto. Los conmutadores VC aplican un mayor nivel de complejidad, ya que manejan atributos como el nivel de errores, calidad de servicio, ancho de banda o servicios relacionados con la tarificación. Lo normal es que los conmutadores que estén sólo conectados a otros conmutadores sean conmutadores VP mientras que los conmutadores VC serán los que se encuentren conectados directamente por algunos de sus puertos a un terminal Funciones y algoritmos de gestión de conexiones de simswitch Una vez presentados los mecanismos que utiliza ATM para la señalización enrutamiento y la gestión de conexiones, seguidamente pasaremos a explicar cuáles serán los mecanismos que utilizará nuestra simulación para realizar todas estas labores. Seguiremos un orden análogo al de los anteriores puntos por lo que primeramente nos centraremos en la señalización, continuaremos describiendo el protocolo de establecimiento y liberación de conexiones, seguiremos profundizando en el método de enrutamiento elegido y finalmente, tras presentar el algoritmo CAC implementado, acabaremos con el método de contrucción y mantenimiento de las tablas VCC Señalización en la simulación La señalización en "simswitch" está basada en la especificación UNI 3.0. Se ha optado por ésta principalmente por el hecho de que las especificaciones posteriores están basadas en ella y son muy similares en cuanto a la señalización. Otra razón es que, como veremos en el apartado de enrutamiento, hemos escogido el protocolo de enrutamiento IISP diseñado para trabajar sobre UNI en cualquier enlace de la red, ya sea entre conmutadores o entre un elemento final y un conmutador. Por último la señalización UNI 3.0 es la más simple y fácil de entender con lo que, además de proveer al simulador de un método de señalización realista, no oscurecemos el código 50

51 con algoritmos y protocolos complicados de implementar y entender Mensajes de señalización En la especificación original los mensajes de señalización se empaquetan en PDUs AAL. Nosotros, debido a la mayor simplicidad de nuestra implementación, los mensajes de señalización los reduciremos a una sola célula por mensaje. Los elementos de la red reconocerán a una célula como "célula de señalización" si al examinar el par VPI/VCI comprueban que pertenece al canal de señalización, el 0/5. Este canal será un circuito virtual permanente en cada enlace y por lo tanto no será necesario su establecimiento previo a la hora de mandar mensajes de señalización. Un tipo de mensaje se diferenciará de otros mediante un "Id de mensaje" presente en el payload de la célula de señalización Tipos de mensajes Los mensajes de señalización que se intercambiarán los elementos de la red entre sí y la información que contendrá cada célula quedan reflejados en la siguiente tabla: Id Nombre Significado Parámetros 0 SETUP Esta función del protocolo permite a un usuario pedir VPI/VCI el establecimiento de una conexión a un cierto destino. Dir. Origen Dir. Destino PCR ToS 1 CALL PROCEEDING Mandado de un usuario a la red o de la red a un usuario para indicar que la el establecimiento de conexión solicitado está siendo iniciado. 2 CONECT El usuario manda este mensaje a la red y la red usuario para indicar la aceptación de la conexión. 3 CONECT La red manda este mensaje a un usuario o un usuario a ACKNOWLEDGE la red para indicar se ha recibido el mensaje CONNECT. 4 RELEASE Un usuario manda este mensaje a la red o la red a un usuario para pedir la finalización de una conexión establecida p-p o p-mp. 5 RELEASE COMPLETE La red manda este mensaje a un usuario o un usuario a la red para confirmar la liberación de la conexión. También es utilizado por la red o por un usuario para rechazar una solicitud de conexión. 6 ADD PARTY Un usuario manda este mensaje a la red o la red lo manda a un usuario para añadir un nuevo receptor a una conexión en conexiones p-mp. Es equivalente al mensaje SETUP. grado GoS VPI/VCI VPI/VCI VPI/VCI VPI/VCI VPI/VCI VPI/VCI Dir Origen Dir Destino PCR ToS grado GoS 51

52 7 ADD PARTY ACKNOWLEDGE Tabla 9.3: Tipos de mensajes de señalización. La red manda este mensaje a un usuario o un usuario a la red para indicar la aceptación del mensaje anterior. VPI/VCI Se fijará el lector en que no hemos introducido ningún mensaje de rechazo de conexiones. Esto es debido a que en nuestro simulador ninguna conexión es rechazada. Lo hemos dispuesto para poder forzar situaciones de congestión a voluntad en los conmutadores de la red. Todas aquellas conexiones que según el CAC no debieran ser aceptadas son, por tanto, admitidas sin reservas. De la misma forma cualquier sumidero aceptará los parámetros de conexión que le proponga una fuente. La única excepción a esta regla se produce cuando una fuente intenta establecer una conexión mediante SETUP o ADD PARTY con un sumidero destino no existente. En tal caso la red responde a la fuente con un mensaje RELEASE COMPLETED. Seguidamente pasamos a explicar más detenidamente cuáles son las funciones de los parámetros de las conexiones. - VPI/VCI --> El par de valores VCI/VPI con el que los datos enviados de la conexión llegarán al elemento en cuestión. En las células SETUP y ADD PARTY se utiliza para inicializar los valores de las tablas VPI/VCI. En las demás células se sirven para localizar la conexión a la que van dirigidas dentro de un elemento.. - Dir Origen, Dir Destino --> Las direcciones únicas del extremo origen y el extremo destino de una conexión. Utilizados como índices en las tablas de enrutamiento de cada conmutador para decidir el puerto de salida de un mensaje de señalización. - PCR --> PCR de la conexión solicitante. Usado para la adjudicación de pesos en las colas del algoritmo WFQA en los conmutadores y como parámetro para el CAC. - ToS --> Tipo de servicio que se solicita al extremo receptor. Puede ser ordenado o no ordenado. - Grado GoS --> Grado de garantía de servicio solicitado. Si su valor es cero la conexión no solicita GoS. Seguidamente expondremos un ejemplo de establecimiento y liberación de conexiones en diagramas temporales para conexiones p-p y p-mp. En el ejemplo p-p vemos como el router A intenta establecer una conexión con el router B a través de dos conmutadores. Se muestra también la interface que actúa en cada lado de la comunicación. 52

53 SETUP SETUP CALL PROCEEDING SETUP CALL PROCEEDING CALL PROCEEDING t CONECT CONECT CONECT ACK CONECT CONECT ACK CONECT ACK ROUTER A CONMUTADOR A CONMUTADOR B ROUTER B Figura 9.2: Cronograma del proceso de establecimiento de conexión con éxito. SETUP t RELEASE COMPLETE ROUTER A CONMUTADOR A CONMUTADOR B ROUTER B Figura 9.3: Cronograma del proceso de establecimiento de conexión sin éxito. RELEASE RELEASE t RELEASE COMPLETE RELEASE RELEASE COMPLETE RELEASE COMPLETE ROUTER A CONMUTADOR A CONMUTADOR B ROUTER B Figura 9.4: Cronograma del proceso de liberación de conexión. 53

54 ADD PARTY ADD PARTY ADD PARTY t ADD PARTY ACK ADD PARTY ACK ADD PARTY ACK ROUTER A CONMUTADOR A CONMUTADOR C ROUTER C Figura 9.5: Cronograma del proceso de adición de un nuevo destino en conexiones p-mp con éxito. ADD PARTY t RELEASE COMPLETE ROUTER A CONMUTADOR A CONMUTADOR B ROUTER B Figura 9.6: Cronograma del proceso de adición de un nuevo destino en conexiones p-mp sin éxito Estados de llamada en conexiones. Debido a que muchas llamadas pueden existir simultáneamente en el UNI, y a que cada llamada puede estar en diferentes estados, se debe definir sin ambigüedades el estado de la interface. Los posibles estados, con sus significados para la interface N y la U son los siguientes: - NULL (0): No hay llamada - CALL INITIATED (1): U: Se ha mandado un mensaje SETUP y se está a la espera de la confirmación. N: Se ha recibido un mensaje SETUP pero aun no se ha confirmado - OUTGOING CALL PROCEEDING (3): U: Se ha recibido confirmación del mensaje SETUP. N: Se ha mandado confirmación al mensaje SETUP recibido. -CALL PRESENT (6): U: Se ha recibido un mensaje SETUP que aun no se ha confirmado. N: Se he enviado un mensaje SETUP que aún no ha sido confirmado. 54

55 -CONNECT REQUEST (8): U: Se ha confirmado un mensaje SETUP recibido. N: Se ha recibido confirmación de un mensaje SETUP enviado - INCOMING CALL PROCEEDING (9): U: Se ha aceptado una petición de conexión con un mensaje CONNECTION. N: Se ha recibido un mensaje CONECCTION aceptando una petición de conexión. - ACTIVE (10): U: Se ha recibido confirmación al mensaje CONNECTION en el extremo receptor de la petición original de conexión. En el caso del emisor, éste pasa al estado ACTIVE cuando envía un mensaje de confirmación de conexión. N: Se ha mandado confirmación al mensaje CONNECTION al extremo receptor de la petición original de conexión o se ha mandado un mensaje CONNECTION al origen de la petición de conexión. - RELEASE REQUEST (11): U: Se manda un mensaje RELEASE de petición de liberación de la conexión aún no confirmado. N: Se recibe un mensaje RELEASE antes de su confirmación. - RELEASE INDICATION (12) U: Se ha recibido un mensaje RELEASE y aún no se ha confirmado N: Se ha mandado un mensaje RELEASE no confirmado aún. Es de importancia diferenciar entre el lado de usuario o el lado de red ya que, como veremos más tarde, según el protocolo de enrutamiento que hemos elegido, el IISP, un conmutador puede arbitrariamente tomar el papel de usuario o red en cada extremo de un enlace. Existen dos estados más asociados con las conexiones p-mp. Estos estados tienen el mismo significado en el lado del usuario o de la red y son los siguientes: - ADD PARTY INITATED (P1): Se ha mandado un mensaje ADD PARTY. - ADD PARTY RECIVED (P2): Se ha recibido un mensaje ADD PARTY. Toda fuente se debe comprometer a no mandar células de datos hasta que no haya establecido la conexión con todos los sumideros de una comunicación p-mp. Debido a que muchas llamadas pueden existir simultáneamente en el UNI, y a que cada llamada puede estar en diferentes estados, se debe definir sin ambigüedades el estado del interface. Los posibles estados, con sus significados para la interface N y la U son los siguientes: - NULL (0): No hay llamada - CALL INITIATED (1): U: Se ha mandado un mensaje SETUP y se está a la espera de la confirmación. N: Se ha recibido un mensaje SETUP pero aun no se ha confirmado - OUTGOING CALL PROCEEDING (3): U: Se ha recibido confirmación del mensaje SETUP. N: Se ha mandado confirmación al mensaje SETUP recibido. -CALL PRESENT (6): U: Se ha recibido un mensaje SETUP que aun no se ha confirmado. N: Se he enviado un mensaje SETUP que aún no ha sido confirmado. -CONNECT REQUEST (8): U: Se ha confirmado un mensaje SETUP recibido. N: Se ha recibido confirmación de un mensaje SETUP enviado - INCOMING CALL PROCEEDING (9): U: Se ha aceptado una petición de conexión con un mensaje CONNECTION. N: Se ha recibido un mensaje CONECCTION aceptando una petición de conexión. 55

56 - ACTIVE (10): U: Se ha recibido confirmación al mensaje CONNECTION en el extremo receptor de la petición original de conexión. En el caso del emisor, éste pasa al estado ACTIVE cuando recibe un mensaje de confirmación de conexión. N: Se ha mandado confirmación al mensaje CONNECTION al extremo receptor de la petición original de conexión o se ha mandado un mensaje CONNECTION al origen de la petición de conexión. - RELEASE REQUEST (11): U: Se manda un mensaje RELEASE de petición de liberación de la conexión aún no confirmado. N: Se recibe un mensaje RELEASE antes de su confirmación. - RELEASE INDICATION (12) U: Se ha recibido un mensaje RELEASE y aún no se ha confirmado N: Se ha mandado un mensaje RELEASE no confirmado aún. Es de importancia diferenciar entre el lado de usuario o el lado de red ya que, como veremos más tarde, según el protocolo de enrutamiento que hemos elegido, el IISP, un conmutador puede arbitrariamente tomar el papel de usuario o red en cada extremo de un enlace. Existen dos estados más asociados con las conexiones p-mp. Estos estados tienen el mismo significado en el lado del usuario o de la red y son los siguientes: - ADD PARTY INITATED (P1): Se ha mandado un mensaje ADD PARTY. - ADD PARTY RECIVED (P2): Se ha recibido un mensaje ADD PARTY. Toda fuente se debe comprometer a no mandar células de datos hasta que no haya establecido la conexión con todos los sumideros de una comunicación p-mp Diagrama de estados de una conexión Seguidamente mostramos el diagrama de estados para las interfaces de usuario y de red. Cada conexión iniciada, en curso o liberándose se encuentra en uno de estos estados. El diagrama a) muestra los estados en la interface de usuario de un elemento que inicia la conexión. El diagrama b) muestra los estados en la interface de usuario pero para un elemento receptor de la petición de conexión. En el c) se muestra el iniciador en la interface N y por último, en el d) se muestra la parte receptora en la interface N. Los textos de los arcos se leen de la siguiente forma: RECIVE EL MENSAJE x/ ENVÍA EL MENSAJE y Si en alguno de las dos partes aparece un signo de multiplicación * querrá decir que se trata de una comunicación entre interfaces. En el caso de que el asterisco aparezca en la primera parte (esto es, antes de / ) se tratará de una notificación recibida de la otra interface. Si por el contrario el asterisco aparece en la segunda parte (esto es, tras / ) indicará que se notifica a la otra interface el mensaje recibido. Por ejemplo, un arco con un texto */SETUP indicará que se ha recibido de la interface de entrada una notificación de llegada de un mensaje de señalización SETUP que provocará que esta interface, la de salida, envíe un mensaje SETUP por donde corresponda. 56

57 Figura 9.7: Diagrama de estados en una fuente Figura 9.8: Diagrama de estados en un sumidero 57

58 Figura 9.9: Diagrama de estados en la interface de entrada en de un conmutador Figura 9.10: Diagrama de estados en la interface de salida en de un conmutado 58

59 Acciones a realizar en cada estado Dependiendo del estado en el que se encuentre una conexión y de los mensajes recibidos o enviados se deberán realizar diferentes acciones. En los siguientes puntos se describen esas acciones para cada estado e interface. - U0.- Una conexión se encuentra en este estado si ha finalizado o está a la espera de activarse. Una fuente con una conexión en este estado deberá comprobar si ha llegado el momento de activarla. Si es así construirá un mensaje SETUP con los datos de la conexión y lo mandará al conmutador al que esté conectado. Un sumidero con una conexión en este estado esperará a un mensaje SETUP tras el cual procederá a inicializar los elementos necesarios para el seguimiento de la conexión. - U1.- Una conexión se encuentra en este estado si está a la espera de recibir un mensaje CALL PROCEEDING o un mensaje RELEASE COMPLETE. Cuando se recibe un CALL PROCEEDING se obtiene el valor de VPI/VCI que nos servirá para diferenciar los mensajes dirigidos a esta conexión de los dirigidos a otras posibles conexiones. Una fuente con una conexión en este estado no iniciará el proceso de abrir ninguna otra conexión. El VPI/VCI seleccionado para esta conexión se obtendrá del mensaje CALL PROCEEDING. Cuando se recibe un RELEASE COMPLETE, la conexión se anula y por lo tanto no se mandará ninguna célula de información para ella. - U3.- Una conexión en este estado se encuentra a la espera de un mensaje CONNECTION confirmando la solicitud de conexión por parte del sumidero. vuelta. - U6.- El sumidero destino construirá un mensaje CALL PROCEEDING y lo mandará de - U8.- El sumidero construirá un mensaje de aceptación de la conexión CONNECTION. - U9.- El sumidero se pone a la espera de recibir la confirmación CONNECTION ACK. La fuente debe enviar un mensaje CONNECTION ACK - U10.- En este estado se diferencia entre el comportamiento de una fuente y un sumidero. Si la comunicación es p-p la fuente empezará el proceso de envío y recepción de datos y células RM. Si se trata de una conexión p-mp se deberá enviar tantos ADD PARTY como destinos diferentes tenga. Una vez añadidos todos estos destinos comenzará el envío de datos. Cuando sea el momento de cerrar la conexión (haya agotado su tiempo de simulación) se mandará un mensaje RELEASE no mandando más células de datos. El sumidero se podrá a la espera de recibir datos o células RM para esta conexión y las procesará como sea conveniente. También esperará un mensaje RELEASE que le ordene liberar la conexión. Cuando ésta se recibe deja de esperar más células de datos de esa conexión - U11.- La fuente, una vez mandado el mensaje de liberación de la conexión, se pondrá a la espera de recibir la confirmación con el mensaje RELEASE COMPLETE. 59

60 - U12.- El sumidero construirá y mandará un mensaje de confirmación RELEASE COMPLETE y destruirá la conexión. Para las interfaces N distinguiremos entre la interface N de entrada y la de salida - N0.- En la interface de entrada un conmutador se encuentra a la espera de recibir una solicitud de conexión SETUP. Al recibirla se pasa al estado siguiente. En la interface de salida el conmutador se encuentra a la espera de que la interface de entrada le comunique que ha recibido una señal SETUP. Entones comprueba las tablas de enrutamiento, se actualizan las tablas VPI/VCI y finalmente se propaga la señal SETUP por la salida seleccionada, y pasa al estado siguiente. - N1.- El la interface de entrada se comprueba la existencia del destino. Si el destino existe se aplica el algoritmo CAC, se comprueba los valores VPI/VCI de entrada y los modifica en caso necesario y se devuelve un mensaje CALL PROCEEDING con el valor adjudicado de VPI/VCI y se actualiza la tabla VPI/VCI. Igualmente comunica a la interface de salida la recepción de un mensaje SETUP haciéndole cambiar de estado (de N0 a N6). Si por el contrario el sumidero no existe se responde a la fuente con un mensaje RELEASE COMPLETE y no se realizan más acciones. Es importante indicar que sólo será posible el envío de este mensaje en el primer conmutador al que llegue el mensaje SETUP - N3.- En este estado la interface de entrada espera a que la interface de salida le comunique que se ha recibido una aceptación de conexión, mensaje CONNECTION, tras lo cual propagará ese mensaje a los elementos precedentes. - N6.- En este estado la interface de salida está esperando una confirmación mediante el mensaje CALL PROCEEDING. - N8.- La interfaz de salida se encuentra esperando un mensaje de conexión aceptada CONNECTION. Al recibirlo le comunica a la interface de entrada el hecho para que propague en sentido descendente este mensaje. - N9.- La interfaz de salida confirma el anterior mensaje con CONNECTION ACK. - N10.- La interface de entrada se pone a la espera de recibir un mensaje CONNECTION ACK tras lo cual esperará recibir las células de datos de la conexión y esperará el mensaje RELEASE. Una vez recibido le comunica este hecho a la interface de salida y pasa al siguiente estado. También puede recibir un mensaje ADD PARTY tras lo cual actuaría como en el estado N0 cambiando al estado P2 y notificándolo a la interfaz de salida. La interfaz de salida esperará a recibir células de datos que serán enviadas por el puerto de salida adecuado. Esta situación se mantendrá hasta que la interface de entrada le comunique que ha recibido un mensaje RELEASE para esta conexión. Entonces propagará este mensaje y pasará al siguiente estado. En el caso de conexiones p-mp el mensaje RELEASE se propagará por todas aquellas salidas que sean necesarias. - N11.- Se liberarán los recursos destinados a mantener esta conexión (colas de entrada, entrada/s en la tabla VPI/VCI, etc.). Por último mandará al origen un mensaje de confirmación RELEASE COMPLETED lo que indicará que la conexión ha sido liberada. - N12.- La interfaz de salida espera la confirmación de la liberación de la conexión 60

61 mediante un mensaje RELEASE COMPLETED. - P1.- Si nos encontramos en la fuente se construye un mensaje ADD PARTY a partir de la información de la conexión. Se envía y se espera confirmación. Si por el contrario este estado se ejecuta en un conmutador, el mensaje se construye a partir del ADD PARTY recibido y se reenvía por donde corresponda según la tabla de enrutamiento. - P2.- Si nos encontramos en el sumidero debemos actuar como si hubiéramos recibido un mensaje SETUP con la diferencia de que tan sólo habrá que mandar de vuelta un mensaje ADD PARTY ACK pasando seguidamente al estado ACTIVO. Si nos encontramos en un conmutador el proceso es diferente. Si el mensaje no ha seguido el camino del SETUP inicial entonces se han de inicializar todas las estructuras como si hubiéramos recibido un mensaje SETUP. Posteriormente se comprueba la función CAC y se pasa a la interface de salida para ser reenviado. Si nos encontramos en un conmutador entonces el mensaje DROP PARTY ACKNOWLEDGE lo habremos recibido de la interface de salida. En este caso se deberán liberar los recursos adjudicados a este destino de la conexión y reexpedir el mensaje por el puerto de entrada que corresponda Direccionamiento en la simulación Las funciones de direccionamiento en nuestro simulador están simplificadas hasta tal punto que cada elemento de una topología queda unívocamente identificado mediante un único número entero, que hará las veces de dirección ATM. Este identificador se inicializa en el momento de crear un elemento de red Enrutamiento en la simulación El protocolo de enrutamiento elegido para la simulación es el IISP descrito en uno de los anteriores apartados. Nuestra elección se debe a que es un protocolo simple, con poca complejidad y adecuado a nuestros propósitos ya que al ser sus tablas de enrutamiento estáticas nos permite más fácilmente forzar rutas específicas a determinadas conexiones. Como vimos, las peticiones de señalización son encaminadas entre conmutadores usando tablas de enrutamiento preconfiguradas en cada conmutador. Esta preconfiguración la realizaremos antes de que cualquier fuente inicie ninguna petición de conexión. En este apartado describiremos qué forma tendrán las tablas de enrutamiento, cómo se utilizarán y qué algoritmos de enrutamiento damos la posibilidad utilizar en nuestra implementación de este protocolo Tablas de enrutamiento: Cada conmutador de nuestra red almacena una tabla de enrutamiento que deberá estar creada e inicializada con los datos de enrutamiento antes de que alguna petición de conexión 61

62 llegue. Las tablas de enrutamiento del algoritmo IISP presentan la siguiente estructura: Dir Destino 1 Dir Destino 2... Dir Destino n Dir Origen 1 PuertoSalida PuertoSalida... PuertoSalida Dir Origen 2 PuertoSalida PuertoSalida... PuertoSalida Dir Origen n PuertoSalida PuertoSalida... PuertoSalida Tabla 9.4: Tablas de enrutamiento IISP Vista la forma de estas tablas se deduce que cada conmutador debe tener conocimiento completo sobre la topología de la red. Como puede verse sólo se almacena el puerto de salida. Para obtener el puerto de entrada no es necesario acudir a las tablas de enrutamiento ya que esta información ya se almacenó cuando llegó la célula SETUP ó ADD PARTY en la señalización Inicialización de las tablas de enrutamiento Como hemos apuntado anteriormente, el algoritmo a utilizar para obtener las matrices de enrutamiento de cada conmutador deberá tener conocimiento de la topología completa de la red, por lo que este algoritmo se calculará una vez finalizado el proceso de diseño de la topología. Para el cálculo de enrutamiento utilizaremos el algoritmo de Floyd. Partimos de un grafo dirigido dado por su matriz de adyacencia y calculado directamente a partir de la topología de la red: G(i, j) = c Si hay un enlace de i a j con coste c e i!= j. G(i, j) = INFINITO Si no hay tal enlace y e!= j. G(i, i) = 0. Posteriormente se aplica el algoritmo y se obtienen la tabla C(i,j) (coste mínimo del camino entre los nodos i y j) y la tabla P(i,j) (nodo intermedio entre i y j en el camino de coste mínimo). El algoritmo es el siguiente: Algoritmo de Floyd. Proc floyd(g[1..n, 1..n], C[1..n, 1..n], P[1..n, 1..n]); C:=G; P:=[0]; Para k=1 hasta n hacer Para i=1 hasta n hacer Para j=1 hasta n hacer Si C(i, k)+c(k, j) < C(i, j) entonces C(i, j) = C(i, k) + C(k, j) P(i, j) = k Fsi; Fpara; 62

63 Fproc; Fpara; Fpara; Lo único que puede quedar un poco oscuro es el objetivo de la matriz P. Esta matriz es la que se utiliza para conocer el camino concreto. Para hacerlo se actúa así, si queremos conocer el camino mínimo entre i y j, calculamos las matrices C y P por el algoritmo anterior, a continuación tomamos P(i, j) = k. Esto significa que el camino mínimo que lleva de i a j pasa por k. Necesitamos conocer el camino mínimo de i a k y de k a j, pero como ya hemos calculado las matrices C y P, consultamos P(i, k) = r y P(k, j) =s. A continuación consultamos P(i, r), P(r, k), P(k, s) y P(s, j)... etc. Si C(i, j) = INFINITO, no hay camino de i a j. Hemos propuesto dos criterios para la inicialización de costes en el grafo G. - La primera basada en la latencia. Los valores de G se rellenan con el delay introducido por el cable en un enlace. Una ruta será más costosa cuanto mayor sea el delay acumulado. Por lo tanto el algoritmo aplicado a este grafo nos dará el camino entre dos nodos i y j que presente la mínima latencia. - La segunda se basa en el número de enlaces que atravesará una conexión. G(i,j) inicialmente sólo contendrá los valores 1 ó 0. Contendrá un 1 si hay camino directo entre i y j y contendrá un 0 en caso contrario. Por lo tanto el algoritmo aplicado a este grafo nos dará el camino entre los nodos i y j que atraviese el menor número de enlaces. Una vez obtenida la matriz P, utilizaremos sus valores para rellenar la matriz de enrutamiento en cada uno de los conmutadores Utilización de una tabla de enrutamiento. Estas tablas sólo las utilizará el conmutador a la hora de dirigir las células de señalización SETUP y ADD PARTY y establecer VCs para las conexiones rellenado las tablas VCC. Cuando se ha de enrutar éstas células de señalización, se examina su payload donde se encuentran sus parámetros "Dir Origen" y "Dir Destino". Se utilizan estos dos parámetros como índices en la tabla de enrutamiento y se obtiene el valor del puerto deseado. El algoritmo en pseudocódigo es el siguiente: function getpuerto( Tabla_routing, SEN_CELL, dirección) return Integer begin return tabla_routing[getdirorigen(sen_cell)] [getdirdestino(sen_cell)] end; El algoritmo CAC en la simulación En nuestro simulador utilizaremos un algoritmo de asignación no estadística muy sencillo. Por las características especiales del simulador necesitamos que TODAS las solicitudes de conexión sean aceptadas. La única misión de este algoritmo es la de avisar al operador de que una determinada conexión puede degenerar el comportamiento de un conmutador pudiéndose 63

64 llegar a producir congestiones. Teniendo en cuenta el papel secundario del CAC en nuestro simulador, la elección de un algoritmo CAC sencillo está completamente justificada. El algoritmo CAC lanzará una alarma de "conexión potencialmente congestionante" al operador cuando, al recibir una célula de señalización SETUP o ADD PARTY y comprobar su propuesta de PCR, comprueba que, añadida al PCR de las conexiones activas, supera la potencia de conmutación del conmutador o el ACR (Avaliable cell rate) de la portadora de salida del puerto correspondiente. El algoritmo en pseudocódigo es el siguiente: function compruebacac(puerto, SETUP, ABR_conmutacion, ABR_puerto) return alarma begin alarma = false; pcr = getpcr(setup) ; if ABR_conmutacion <= 0 or pcr > ABR_conmutacion then alarma = true; if ABR_puerto[puerto] <= 0 or pcr > ABR_puerto[puerto] then alarma = true; ABR_conmutacion = ABR_conmutacion - pcr; ABR_puerto[puerto] = ABR_puerto[puerto] - pcr; return alarma; end function; Como puede verse necesitamos también los valores del ABR de conmutación y ABR de salida. Pase lo que pase el ABR se reduce en una cantidad igual al PCR solicitado por la conexión. Cuando la conexión se cierra el ABR se aumentará en la misma cantidad que fue disminuido en la apertura Tablas de enrutamiento de VCCs en la simulación En nuestra simulación las tablas de enrutamiento están diseñadas exactamente como describimos en anteriores apartados. Cada conmutador almacenará una de estas tablas cuyos valores internos cambiarán dinámicamente durante el transcurso de la simulación en reacción a peticiones de señalización. Las tablas VCCs estarán indexadas por dos ternas de valores. La primera terna, la llamada "terna de entrada" contendrá primeramente el valor del puerto de entrada de una conexión seguido del VPI y del VCI adjudicado a esa conexión. La segunda terna, la "terna de salida" contendrá una lista de ternas, una por cada puerto de salida diferente en una conexión p- mp. Para cada elemento de la lista aparecerá primeramente el valor del puerto de salida, y después el del VPI y del VCI con el que saldrán todas las células de la conexión en cuestión. Terna de Entrada Ternas de Salida Puerto VPI VCI [0] Puerto VPI VCI [n] Puerto VPI VCI Tabla 9.5: Tabla VCC 64

65 Establecimiento de VCCs Cuando un conmutador recibe una petición de establecimiento de conexión mediante una célula de señalización SETUP, una vez ésta ha pasado el filtro del CAC, se debe crear una entrada en la tabla VPI/VCI para este nueva conexión. Los pasos a seguir son los siguientes: 1.- En la solicitud SETUP están presentes dos valores que son el par VPI/VCI solicitado. Debido a que en una fuente no se pueden programar dos conexiones con valores VPI/VCI idénticos, y a la forma de asignación de ese para en los conmutadores, a un conmutador no le pueden llegar por el mismo puerto de entrada dos solicitudes con VPI/VCI idénticos. 2.- El conmutador crea una nueva línea en la terna de entrada en la tabla VPI/VCI con los valores del puerto por el que entró la célula de señalización y el VPI/VCI adjudicados 3.- Posteriormente adjudica los dos valores del par VPI/VCI de la terna de salida siguiendo los siguientes criterios: - El VPI de salida será idéntico para todas las células de aquellas conexiones que compartan el mismo sumidero destino. Esto se hace así para facilitar el enrutamiento VP en los conmutadores intermedios. Para ello cada conmutador debe guardar un registro del VPI de salida utilizado para cada sumidero. Para simplificar esto, a este VPI se le adjudicará el valor de "Id Destino" presente en todas las células de señalización, consiguiendo así el requerimiento anterior. - El VCI de salida será diferente para cada conexión que comparta un puerto y un VPI de salida. De esta forma diferenciaremos unas conexiones de otras dirigidas al mismo sumidero. Para implementar esto deberemos mantener un registro de los VCI utilizados para cada VPI. El valor VPI adjudicado será más bajo que se encuentre libre en el registro, y lo marcaremos seguidamente como ocupado. 4.- Con los valores obtenidos del par VPI/VCI de salida y el puerto de salida se crea una terna de salida y se asocia a la terna de entrada obtenida. *.- En el caso de las conexiones p-mp, si a un conmutador le llega una célula ADD PARTY deberá comprobar el VPI/VCI y el puerto de entrada para ver si la conexión ha sido ya previamente restablecida en el conmutador. Si es así no deberá crear una nueva línea en la terna de entrada, en caso contrario procederá siguiendo los pasos 2 a 4. Si la terna de entrada ya estaba establecida entonces se obtendrá el puerto de salida y se comparará con el campo puerto de salida de la lista de ternas de salida. Si es igual a alguna de ellas querrá decir que ambas conexiones saldrán por el mismo puerto por lo que no será necesario añadir ninguna terna de salida a la/s ya presente/s. Si el puerto de salida no coincide con ninguno de la lista querrá decir que este conmutador debe mandar los mismos datos de esta conexión por dos o más puertos diferentes. En consecuencia deberá añadir una nueva terna a la lista de ternas de salida siguiendo los puntos 3 y 4. 65

66 Pseudocódigo: procedure addvcc(sen_cell, puerto_entrada, puerto_salida) begin VPI/VCI_entrada = getvpi/vci(sen_cell); if tipo(sen_cell) = SETUP or (tipo(sen_cell) = ADD PARTY and not conexionpresente(puerto_entrada, VPI/VCI_entrada) then begin VPI/VCI_adjudicado = getvpi/vci_libre(tablavcc, VPI/VCI_entrada); terna_entrada = addternaentrada(tablavccs, puerto_entrada, VPI/VCI_adjudicado); VPI_salida = getdirdestino(sen_cell); VCI_salida = getvcilibre(puerto_salida, VPI_salida); addternasalida(terna_entrada, puerto_salida, VPI/VCI_salida); else begin terma_entrada = getternaentrada(tablavccs, puerto_entrada, VPI/VCI_entrada) if puertosalidanuevo(terna_entrada, puerto_salida, tablavcc) then begin VPI_salida = getdirdestino(sen_cell); VCI_salida = getvcilibre(puerto_salida, VPI_salida); addternasalida(terna_entrada, puerto_salida, VPI/VCI_salida); end if end if end procedure; Liberación de VCCs La liberación de conexiones se iniciará en el caso de que a un conmutador le llegue un mensaje de señalización RELEASE. Los pasos a seguir son los siguientes: 1.- Se comprueba si el VC está activo. Para ello examinamos la tabla VCCs y utilizamos el valor VPI/VCI y puerto de entrada como índice. 2.- Si está activo simplemente se borra de la tabla VCC la terna de entrada con su/s correspondiente/s terna/s de salida. Pseudocódigo procedure delvcc(sen_cell, puerto_entrada) begin VPI/VCI = getvpi/vci(sen_cell); if conexionpresente(puerto_entrada, VPI/VCI) then begin terma_entrada = getternaentrada(tablavccs, puerto_entrada, VPI/VCI) end if; end procedure; delternassalida( tabla VCCs, terna_entrada); delternaentrada( tabla VCCs, puerto_entrada, VPI/VCI); Uso de las tablas VCCs Cuando a algún conmutador llega una célula de datos, para conmutarla al puerto de salida 66

67 adecuado con los valore VPI/VCI correctos debe consultar la tabla VCCs. Para ello necesitará los valores de la terna de entrada. Como resultado obtendrá una lista consistente en una ó más de ternas con la información necesaria para la conmutación. Pseudocódigo procedure getternassalida(puerto_entrada, VPI/VCI_entrada) return Cjto_ternas_salida begin terna_entrada = getternaentrada(tablavcc, puerto_entrada, VPI/VCI_entrada); Cjto_ternas_salida = getternassalida(tablavcc, terna_entrada); return Cjto_ternas_Salida; end procedure; 67

68 10. Funciones y procedimientos para la gestión del tráfico Introducción En este apartado vamos a indicar los diferentes mecanismos que es posible utilizar en ATM para el control del tráfico y las congestiones. Las redes ATM reales pueden implementar una o una combinación de estas funciones con el fin de obtener los objetivos de QoS especificados en las conexiones. En nuestro simulador no hemos tenido en cuenta los parámetros de QoS. Las razones de ello son varias: Por una parte no existen algoritmos estándar para la consecución de la QoS. Cada fabricante proporciona los parámetros negociados a una conexión mediante sus propios mecanismos propietarios. En segundo lugar, en el caso de que nos decidiéramos a implementar algún mecanismo de QoS, no compensaría la complejidad introducida con los beneficios obtenidos. No olvidemos que el objetivo principal del simulador es el de crear un entorno de red ATM relativamente realista e idóneo para comprobar el grado de GoS obtenido mediante la implantación en las VPN de conmutadores activos que soporten el protocolo TAP. Cuantos más algoritmos haya modificando el tráfico por su cuenta menos clara quedará la aportación del protocolo TAP a la mejora de la red. Un factor importante y relacionado con el anterior punto es el tiempo de cómputo. Nuestro propósito es el de crear un simulador que pueda realizar las simulaciones lo más cercanas posibles al tiempo real. La introducción de los parámetros de QoS en el simulador haría considerablemente más complejos los conmutadores por lo que afectaría negativamente al tiempo de simulación. Esto es así ya que cuanto más complejo sea un conmutador más tiempo llevará que realice sus operaciones y por lo tanto más lento hará el proceso de simulación. El protocolo TAP no está directamente relacionado con la QoS. Cierto es que los agentes controlan la mayoría de los aspectos de la múltiplexación de células en los conmutadores sin embargo no son los responsables directos de la ejecución de los algoritmos dedicados a la consecución de la QoS. Por último, uno de nuestros objetivos a la hora de crear el simulador es hacer el tráfico de la red lo más determinista posible para poder así crear situaciones de congestión en los conmutadores, observar los resultados y poder reproducirlos con posterioridad si fuese necesario. Un simulador con control de la QoS reduciría el grado de determinismo lo que impediría la fácil comparación de resultados entre varias simulaciones. En definitiva, dado que la GoS no está relacionada directamente con la QoS, y que la introducción del manejo de los parámetros de QoS tan solo oscurecería y complicaría nuestro simulador, para nuestros propósitos, de ahora en adelante supondremos que ninguna conexión va 68

69 a requerir que la VPN satisfacer los requerimientos de QoS (CDV, CDT, CLR, etc). Por lo tanto no será necesaria la simulación de la negociación de tales parámetros ni su impacto en el tráfico. Volviendo al tema que nos ocupa en este apartado, describiremos las siguientes funciones para el control de tráfico y congestiones indicando para cada una de ellas si se ha implementado en nuestro simulador, de qué manera y por qué. Las funciones son las siguientes: Connection Admisión Control (Control de admisión de conexiones) Usage Parameter Control (Control de parámetros de uso) Selective Cell Discarding (Descarte selectivo de células) Traffic Shaping (Modelado de tráfico) Explicit Forward Congestion Indication (Indicación explicita de congestión ascendente) Resource Magnagement using Virtual Paths (Gestión de recursos mediante el uso de VPs) Frame Discart (Descarte de marcos) Generic Flow Control (Control de flujo genérico) ABR Flow Control (Control de flujo ABR) Connection Admisión Control La función del control de admisión de conexiones (CAC) se define como el conjunto de acciones tomadas por la red en el establecimiento de un SVC o por la gestión de la red durante el establecimiento de un PVC para determinar qué conexiones deben ser admitidas o rechazadas. En nuestro simulador implementamos una versión muy simple de esta función que utilizamos para comprobar qué conexiones podrían causar congestión Usage Parameter Control La función UPC es opcional en las redes reales. El control de los parámetros de uso (UPC) se define como el conjunto de acciones tomadas por la red para monitorizar y controlar el tráfico. Su propósito principal es proteger los recursos de la red de fallos de comportamiento maliciosos u accidentales que puedan afectar la QoS de otras conexiones establecidas mediante la detección de violaciones de los parámetros negociados y la toma de decisiones apropiadas. En el caso de nuestro simulador esta función no será necesaria por varios motivos: primeramente, como ya apuntamos al comienzo de este capítulo, nosotros no implementamos QoS. Además, dadas las características específicas de nuestra simulación, las fuentes no generan nunca tráfico a una velocidad mayor a la indicada en la conexión por lo que los fallos accidentales o maliciosos en los que una fuente utiliza más ancho de banda del adjudicado no se producen. 69

70 10.4. Selective Cell Discard El descarte selectivo es una función opcional en las redes ATM reales. Un elemento de red congestionado puede selectivamente descartar células que pueden encontrarse en una o ambas de las siguientes situaciones: a) No cumple las condiciones de la conexión b) Presenta su CLP = 1 El objetivo de esta función es el de proteger el CLP = 0 lo máximo posible. Esta función está parcialmente implementada en nuestro simulador. En lo que respecta al apartado a) todas las células no congestionadas llegan en el momento en el que tienen que llegar a los diversos elementos de la red por lo que siempre cumplirán las condiciones de la conexión. En lo que respecta al apartado b) en igualdades de condiciones con conexiones no privilegiadas, en un buffer que ha alcanzado su umbral no se almacenarán células con el CLP = 1, las cuales serán descartadas, mientras que las células con su CLP = 0 sí se almacenarán hasta que se llegue al límite de capacidad del buffer Traffic Shaping El moldeado de tráfico es un mecanismo que altera las características de tráfico de un flujo de células de una conexión para conseguir mejor eficiencia mientras que se consiguen los objetivos de QoS. Debido a que esta técnica va principalmente dirigida a la consecución de parámetros de QoS hemos decidido obviarla en nuestro simulador Explicit Forward Congestion Indication La aplicación de técnicas de indicación de congestión ascendente explícita (EFCI) es opcional para una red ATM. Un elemento de red en un inminente estado de congestión o ya en él puede establecer en EFCI en la cabecera de la célula para que esta indicación pueda ser examinada por los terminales sumideros de las conexiones. Por ejemplo, una fuente puede usar este indicador para implementar un protocolo que de forma adaptativa disminuye la velocidad de la conexión durante las congestiones o posibles congestiones inminentes. Un elemento de red que no esté en estado de congestión o en un estado de congestión inminente no modificará el valor de este indicador. Un estado de congestión inminente es aquel en el que el elemento de la red está operando alrededor de su capacidad máxima calculada. 70

71 Este servicio ha sido desarrollado para categorías de servicio CBR, VBR y UBR. Como veremos posteriormente para ABR existe otro mecanismo de control de congestiones en los terminales el cual se encuentra implementado parcialmente en nuestro simulador. En el capítulo 12 presentamos las categorías de servicios que soportaría el simulador (ABR y UBR) y las razones de esta elección. Dado que la categoría UBR la incluimos para las conexiones a las que no queremos que se le aplique ningún mecanismo de prevención de congestiones, y que la ABR tiene el suyo propio, no creemos necesario incluir este mecanismo, el EFCI, en nuestro simulador Resource Management using Virtual Paths Los Virtual Paths son un concepto importante del control de tráfico y la gestión de recursos en las redes ATM. En relación con el control de tráfico, los VPCs se pueden utilizar para: Simplificar el CAC; Implementar una forma de control de prioridades segmentando grupos de conexiones virtuales de acuerdo a su categoría de servicio. Conseguir una forma eficiente de distribuir mensajes para las operaciones de control de tráfico (por ejemplo indicar congestión en una red distribuyendo un mensaje simple para todos los VCCs de un VPC determinado); Los VPC también juegan un papel clave en la gestión de recursos. Mediante la reserva de capacidad para los VPC, el tiempo de establecimiento de VCCs se reduce. En definitiva, mediante el agrupado de VCCs en VPCs obtenemos dos niveles de abstracción; por una parte podemos abstraer el control de un gran número de conexiones con requerimientos similares al control de un solo VPC y por la otra podemos manejar las características los VCCs dentro de un VPC sin tener que preocuparnos de los cientos o miles de VCCs presentes en otros VPCs Frame Discard Si un elemento de la red necesita descartar células, en muchos casos es más efectivo un descarte a nivel de marcos que a nivel de células. Un marco en una unidad de protocolo AAL. La red detecta los marcos examinando el campo SDU-type en el payload de la célula de cabeza. El descarte de marcos puede ayudar a evitar el colapso por congestión e incrementar el goodput. Como se explica en el capítulo 15, los conmutadores activos de nuestro simulador contienen buffers de salida con mecanismos de control de congestión que evitan la fragmentación de PDUs. Uno de las acciones que realiza este mecanismo es el descarte de marcos que se prevé no cabrán enteros en el buffer. Por lo tanto se puede decir que en el simulador se implementa un procedimiento de descarte de marcos. 71

72 10.9. Generic Flow Control El campo GFC está presente sólo en las células entre un host y la red; es sobrescrito por el primer conmutador al que llega, por lo que no tiene un significado de terminal a terminal, y no se entrega al destino. Originalmente se pensó que este campo tendría alguna utilidad para el control de flujo o de prioridad entre los hosts y las redes, pero no hay valores definidos para él, y la red lo ignora. Por tanto el uso del campo GFC de las células en la interfaz UNI no se contempla en este documento. No hay valores definidos para el GFC y nuestro simulador, por tanto nunca es examinado ABR Flow Control En el servicio ABR, la fuente adapta su velocidad para adaptarse a las condiciones de la red. La información acerca del estado de la red como la disponibilidad de ancho de banda, estado de congestión y congestión inminente se comunica a la fuente mediante células de control especiales llamadas Resource Managemente Cells (células RM). Nuestro simulador soporta la categoría ABR junto con una versión simplificada del modelo de control de flujo ABR. Para ver la descripción de este modelo y ver el capítulo 3 dedicado a la implementación de las categorías de servicio ABR y UBR. 11. Categorías de servicio implementadas Para los propósitos de nuestro simulador hemos implementado las categorías de servicio ABR y UBR con limitaciones. Las razones de esta elección son varias: Primeramente por la naturaleza del tráfico que se va a simular ya que las categorías de servicio ABR y UBR son la propuesta estándar de ATM para soportar el tráfico de datos, que precisamente es el tipo de datos para el que está pensada la GoS. Por otra parte, mientras que ABR tiene la capacidad de reducir su ritmo de envío de tráfico mediante realimentación con células BRM si se producen congestiones en la red, la categoría UBR no hace promesas y no realimenta información sobre los congestionamientos. En nuestra simulación, en algunas ocasiones forzaremos a que en algún conmutador se produzca congestión para observar el comportamiento del protocolo TAP ante tales situaciones. Si tan solo utilizáramos la categoría de servicio ABR, al tener un sistema autorregulador de flujo ante congestiones, no podríamos estudiar de manera aislada los mecanismos activados por el protocolo TAP y su impacto en el entorno de la simulación. En el otro extremo, si tan solo implementáramos la categoría UBR, no podríamos comprobar el funcionamiento conjunto del protocolo TAP junto con los sistemas de realimentación de ABR y dar una medida del auténtico 72

73 potencial de ambos mecanismos funcionando conjuntamente para la prevención de congestiones por un lado y la minimización de los prejuicios ocasionados por ellas por el otro. Otra razón para elegir aquellas dos categorías es que a pesar de que el protocolo TAP se propuso principalmente para la categoría UBR necesitamos una referencia con alguna otra categoría de servicio y sus formas de combatir o prevenir la congestión para comparar resultados y sacar conclusiones. Con una VPN simulada en la que pudiesen convivir conexiones tanto ABR como UBR tendríamos una base para poder crear gran cantidad de supuestos y situaciones que ajustasen a nuestros requerimientos y poder demostrar, en la medida de nuestras posibilidades, con casos prácticos, la viabilidad del protocolo TAP en una VPN real. Por otro lado, al prescindir de las otras dos categorías de servicio especificadas para ATM (CBR y VBR) no podremos comprobar el impacto de añadir conexiones que requieran una alta calidad de servicio de tiempo real en el comportamiento de la VPN ya que nuestra versión de ABR y UBR no requieren limitaciones en el retado ni en la variabilidad de retardo. Sin embargo, al estar la propuesta TAP dirigida al tráfico de datos sin requerimientos de tiempo real, no consideramos necesario la inclusión de las categorías antes citadas Las categorías de servicio ABR y UBR Estas categorías de servicio están pensadas, como apuntamos en la introducción al capítulo, para aplicaciones sin requerimientos de tiempo real. Se diferencian entre ellas en la naturaleza de los servicios proporcionados por la red y los mecanismos que se implementan en los sistemas terminales y la red para proporcionarlos. La elección de una categoría de servicio será específica para cada aplicación ABR-l En este apartado vamos a describir las características de esta categoría de servicio en nuestro simulador. Como avisamos en el apartado anterior, se han suprimido todos los mecanismos derivados de la introducción de la QoS y otros muchos han sido simplificados. Con el fin de diferenciar la categoría de servicio que nosotros implementamos con la especificada por la ITU-T, a la nuestra la denominamos ABR-l (ABR little) Modelo de servicio detallado para ABR-l Los siguientes puntos resumen algunas propiedades del servicio ABR-l: El objetivo del servicio ABR-l es proveer rápido acceso al ancho de banda no usado por la red hasta el límite de PCR, siempre que la red tenga ancho de banda disponible. Debe ser aplicable tanto a VCCs como a VPCs. 73

74 El MCR se negocia independientemente para cada dirección en una conexión bidireccional ABR-l. Una fuente puede que esté obligada a enviar a una velocidad menor que MCR cuando se está negociando una MCR > 0. La velocidad de envío de una fuente en una conexión nunca será menor que MCR. El MCR negociado variará entre cero y el mayor valor soportado por la red. Este valor máximo puede ser igualmente cero. Si la fuente no indica un MCR, se supondrá el valor por defecto que es cero. A cada conexión se le asignará el valor máximo de MCR que el ancho de banda de la red pueda soportar por estricto orden temporal de llegada de peticiones de conexión. Hemos querido que sea así, en contrapartida a la asignación justa de recursos de la red que se aplica en redes ATM reales, para proporcionarnos la posibilidad de provocar congestiones en elementos específicos de la red. Aunque la red se compromete a soportar el MCR de cada fuente, puede que alguna reciba indicaciones de reducir esta velocidad bajo el MCR. Si alguna fuente recibe la indicación de bajar la velocidad por debajo de su MCR lo que debe hacer es reducirla hasta el MCR. Si una fuente está transmitiendo al MCR y recibe indicaciones de bajar la velocidad, la fuente no necesitará hacer ningún cambio. Durante el establecimiento de conexiones para una conexión con un MCR = 0, el CAC no bloqueará dicha conexión por causa del ancho de banda reservado para otras conexiones. Realmente el CAC en nuestro simulador únicamente avisa si una conexión tiene probabilidad de provocar congestiones sin tomar ninguna decisión Modelo de control de flujo para ABR-l El control de flujo ABR sucede entre la fuente y el sumidero de una conexión. Las fuentes y destinos se encuentran conectadas mediante conexiones bidireccionales. En aras de la simplicidad en nuestro simulador los flujos de datos serán unidireccionales, de la fuente al sumidero, mientras que solo las células RM y las de señalización asociada a la conexión circularán en sentido descendente. La dirección ascendente es la que va desde la Fuente hasta el sumidero mientras que la descendente es en sentido contrario. Para el flujo de información ascendente existe un bucle de control de dos flujos de células RM, uno ascendente y otro descendente. La fuente generará células RM ascendentes que darán la vuelta al llegar al sumidero y volverán a su origen (FRM si son ascendentes o BRM si son descendentes) Las BRM llevan información de realimentación suministrada por los conmutadores de la red. En una red ATM real un elemento de red puede: Insertar directamente información de realimentación en las células RM cuando pasa en la dirección ascendente o descendente. Informar indirectamente a la fuente acerca de una congestión estableciendo el bit EFCI en la cabecera de las células de datos en la dirección ascendente del flujo de información. En este caso el sumidero actualizará la BRM basándose en esta información de congestión. Generar BRMs. En nuestra simulación, para el control de congestiones utilizamos el primer y el tercer método. Como indicamos en el capítulo 2 no utilizaremos el control de flujo basado en EFCI. Emplearemos el primer método para el control de congestiones normalizado de ABR-l. Además 74

75 el método utilizado para dar a conocer la situación en la que se detecta la pérdida de una trama congestionada con el fin de solicitar retransmisiones será el tercero Parámetros de servicio ABR-l En esta sección presentamos los parámetros utilizados en el simulador para implementar al control de flujo ABR-l. En el servicio ABR real existen algunos parámetros más pero han sido suprimidos por no ser necesarios en nuestro nivel de simulación Parámetro Descripción Unidades y rango PCR La velocidad de célula pico, Peak Cell Rate, es la Células/seg velocidad que la fuente nunca excederá. MCR La velocidad mínima de célula, Minimum Cell Rate, es Céluas/seg la velocidad a la que la fuente le está siempre permitido enviar ICR La Velocidad de Célula Inicial, Inital Cell Rate, es la Células/seg velocidad a la que la fuente envía inicialmente. RIF El Factor de Incremento de Velocidad, Rate Increase Factor, controla el aumento de velocidad que la fuente puede aplicar tras recibir una célula RM RDF ACR El Factor de Decremento de Velocidad, Rate Decrease Factor, controla el decremento de la velocidad de transmisión. La Velocidad de Célula Permitida, Allowed Cell Rate, es la velocidad actual a la que la fuente se le está permitido enviar. Tabla 11.1: Parámetros de servicio ABR-l Potencia de dos, desde 1/32768 hasta 1 Potencia de dos Células/segundo Los parámetros señalados en negrita se negocian durante el establecimiento de la conexión. Si no se especifica algún parámetro se sustituye por un valor por defecto Estructura de las células RM La siguiente tabla muestra los campos y su posición en el formato de célula RM. 75

76 Tabla 11.2: Campos de una célula RM. En nuestra simulación no utilizamos todos los campos anteriores. Como se explicó en el capítulo 10, los bits del 21 al 51 se utilizan para las retransmisiones locales. Seguidamente los parámetros utilizados para la implementación del control de flujo ABR-l. Header: Los cinco primeros bytes de una célula RM corresponden a la cabecera estándar de una célula ATM con PTI = 110 (binario), y CLP = 1. DIR: indica la dirección del flujo RM. Si es ascendente DIR = 0 y si es descendente DIR = 1. Cuando la célula llega al destino DIR cambia de 0 a 1. CI: Cuando una fuente detecta una BRM con este bit a 1 entonces decrementará su ACR. NI: Este bit se utiliza para indicar a una fuente que no aumente su ACR. Puede ser utilizado por un conmutador para indicar congestiones inminentes Comportamiento de la fuente 1. El valor de ACR nunca excederá el valor de PCR ni será menor que MCR. 2. Antes de que una fuente envíe su primera célula después del establecimiento de una conexión establecerá ACR a ICR. 3. Se enviará una FRM cada 32 células de datos. En un servicio ABR real la cadencia de envíos de células FRM depende de diversos parámetros como Mrm y Nrm. Hemos considerado una cadencia de células RM fija para simplificar la implementación. 4. Cuando una fuente recibe una célula BRM con el bit CI = 1 entonces la fuente reducirá su ACR por lo menos en ACR * RDF, a no ser que de esta reducción resulte un valor menor que MCR en cuyo caso se establecería ABR = MCR. Si en la célula BRM CI = 0 y NI = 0 entonces la fuente debe incrementar ACR en no más del RIF * PCR, a un valor no mayor que PCR. Si NI = 1 entonces la fuente no incrementará ACR. 76

77 Comportamiento del sumidero En nuestro servicio ABR-l el sumidero actuará únicamente como pared donde rebotarán las células FRM emitidas por la fuente. 1. Cuando recibe una célula FRM el sumidero debe transmitir la célula en sentido contrario para devolverla a la fuente. Cambiará el bit DIR de ascendente a descendente. 2. En nuestro ABR-l, por la misma razón que en punto anterior, un sumidero no podrá generar células BRM Comportamiento de los conmutadores Nuestros conmutadores implementan un método de control de flujo basado en los campos CI y NI. 1. Un conmutador puede generar una célula BRM a alguna fuente cuando detecta que alguno de sus puntos de encolamiento está a punto de experimentar una congestión (con lo que generará una BRM con el bit NI = 1) o cuando detecta una congestión (generará una BRM con el CI = 1) La velocidad máxima de creación de estas células no sobrepasará las 10 células / s. El bit BN = 1 y DIR = 1 2. Cuando a un conmutador llega una RM ya sea ascendente o descendente, seguirá la política descrita en el punto 1 para los bits CI y NI y posteriormente la enviará por donde corresponda Algoritmos en pseudocódigo Seguidamente presentamos el algoritmo utilizado en la fuente y el sumidero de una comunicación ABR-l. Inicialización por conexión ACR = ICR Time_to_send = 32 Pseudocódigo de envío en la fuente if now >= time_to_send then send RM(DIR=forward, CI=0, NI=0, CLP=1) now = 0; end if; Si es el momento de enviar Enviamos RM now es un contador que almacena el número de células de datos que se han enviado. Cuando el valor llega a time_to_send, indica que es el momento de insertar una célula RM en el tráfico. 77

78 Pseudocódigo de recepción en la fuente If receive RM(DIR = backward, CI, NI, BN) then If CI=1 then ACR = ACR ACR*RDF; ACR = max(mcr, ACR); Else if NI = 0 then ACR = ACR + RIF*PCR; ACR = min (ACR, PCR); End if End if Ajustamos ACR Si congestión Disminuimos Si no inminente Aumentamos Pseudocódigo de recepción en el sumidero If receive RM(DIR= forward, CI, NI, BN) then Send RM(DIR=backward, CI, NI); End if; Acción de rebote UBR-l Como hicimos con ABR, creando nuestra propia versión ABR-l, a la adaptación de la clase de servicio UBR la llamaremos en adelante UBR-l. En esta categoría de servicio la fuente de la comunicación emite a una tasa constante de células dada por PCR. Los conmutadores aceptan todas las células UBR-l y, si sobra capacidad, también se entregan. Si ocurren congestionamientos, se descartan las células UBR-l sin realimentación a la fuente y sin esperar que ésta reduzca su velocidad. La categoría UBR es razonable para aplicaciones que no tienen restricciones de entrega y quieren llevar ellas mismas su propio control de errores y de flujo. Proponemos como posible utilización de las fuentes UBRl en nuestro simulador la de focos generadores de congestiones. 78

79 12. Simulaciones SIMULACIONES En este módulo vamos a exponer los resultados obtenidos en la simulación de diferentes topologías con diversas conexiones. Como objetivo principal nos proponemos demostrar los beneficios resultantes de introducir conmutadores AcTM en redes ATM. Estos beneficios serán consecuencia de las retransmisiones locales entre conmutadores AcTM en contraposición a las retransmisiones extremo a extremo propias de protocolos de capas superiores como, por ejemplo, el TCP/IP. En una red con AcTMs, al congestionar una trama en un conmutador AcTM, éste enviará una petición de retransmisión de dicha trama congestionada en la trayectoria inversa a la seguida por ella en una célula RM. Un conmutador AcTM que reciba una petición de retransmisión deberá buscar en su memoria DMTE la trama solicitada. Si está presente se retransmitirá hacia el solicitante, en caso contrario la petición se propagará hacia conmutadores anteriores. En la realización de este proceso aparentemente sencillo intervienen multitud de factores y elementos. Además, el usuario, a la hora de configurar la red y las conexiones, puede intervenir en algunos de aquellos factores y elementos alterando parámetros configurables. En los siguientes puntos exponemos algunos de estos factores y elementos con sus consecuencias previstas en el tráfico: Ubicación de AcTMs: En una topología mixta donde coexistan conmutadores activos y no activos debería ser importante la colocación de los AcTMs. Se intuye que cuanto más cerca estén los conmutadores activos entre si, mayor será el beneficio de las retransmisiones locales. Delays: por la misma razón anterior el delays entre conmutadores activos es importante e influyente ya que provocarán mayor lentitud en las retransmisiones. Tamaños de memoria: Es un parámetro configurable muy importante por una razón muy sencilla, cuanto mayor sea la memoria disponible en el buffer o DMTE en los conmutadores menor será la posibilidad de congestión y mayor la de retransmisión local. GoS: El parámetro de garantía de servicio en una conexión privilegiada tendrá mucha importancia a la hora de la realización de las retransmisiones locales ya que cuanto mayor sea éste mayor será la probabilidad de que aquéllas puedan ser realizadas con éxito. Algoritmos: Los algoritmos predominantes que pueden alterar el comportamiento del tráfico son el EPDR y el WFQA. El principal de ellos es el EPDR. Mediante la alteración del valor del umbral el usuario debería ser capaz de configurar el buffer de un conmutador AcTM para que se comporte de manera óptima según el tráfico predominante. El WFQA tendrá más relevancia cuanto más diferentes sean las velocidades de salida contratada para las fuentes ya que este algoritmo da prioridad a las conexiones procedentes de fuentes más rápidas. Tamaños de trama EAAL: Debería tener influencia directa sobre el comportamiento del algoritmo EPDR. Cuanto mayor sean las trama menores posibilidades habrá de que ésta quepa en el búfer según los requisitos de EPDR. 79

80 En posteriores apartados nos dedicaremos a comprobar y ratificar o corregir las afirmaciones hechas en los anteriores puntos. Para ello expondremos los resultados obtenidos mediante la realización de múltiples simulaciones mediante el paquete software desarrollado para este proyecto. Todos los archivos obtenidos (.top,.fis,.dgs,.cfg) en la realización de estas simulaciones están almacenados en el CD adjunto a este documento para posibilitar así la verificación de los resultados obtenidos La Topología Base Para poder comparar los resultados obtenidos en las diferentes simulaciones éstas deben realizarse sobre topologías similares. Partiremos pues de una topología común que modificaremos ligeramente para observar las consecuencias de dichas modificaciones. La topología elegida es la siguiente: Fig 22.1: Topología de base. Los elementos que intervienen en ella son los siguientes: Conmutadores: Partimos de una red cuyos conmutadores son es su totalidad activos. En un posterior apartado estudiaremos qué ocurriría con topologías mixtas. Fuentes: Hemos creado cuatro fuentes ATM para crear tráfico de fondo (nativo ATM), una fuente EAAL que creará tráfico con requerimientos de GoS y una fuente AAL sin requerimientos de GoS. Sumideros: Existen dos sumideros para recibir el tráfico de fondo y un sumidero por cada fuente AAL y EAAL. Cada uno recibirá el tráfico correspondiente a su nombre. 80

81 Esta topología está pensada para crear situaciones de congestión en los conmutadores CA_6 y CA_7. Esto se consigue gracias al tráfico creado por las fuentes F_ATM_x. Estas fuentes envían al conmutador al que están conectados tráficos a ráfagas en forma de células ATM a una velocidad superior a la que el conmutador es capaz de sacarlo del buffer. Lo que se pretende es que le búfer se llene y se vacíe alternativamente para poder comprobar el comportamiento del tráfico de tramas en distintos valores de llenado de búfer. Por cada uno de los dos conmutadores potencialmente congestionables circularán las tramas creadas por las fuentes AAL y EAAL de manera que el tráfico EAAL atravesará CA_6 y el tráfico AAL atravesará el CA_7. La gráfica de llenado de búfer de los conmutadores CA_6 y CA_7 es la siguiente: Gráfica 22.2: Gráfica de variación de llenado del buffer en relación al tiempo. Como alternativa podríamos optar por conexiones ABR adaptativas cuyo tráfico podría ser similar en lo referente a los picos y los valles. Sin embargo este tipo de tráfico podría oscurecer los resultados obtenidos debido a su misma variabilidad con las condiciones del búfer. Lo que buscamos en un tráfico de fondo constante y fijo donde poder comparar distintos factores variables. El delay de todos los cables ha sido ajustado a 2-4 ms de manera que podamos establecer un valor de tick de 100ns lo que aumentará la velocidad de simulación al tiempo de que el decremento del realismo es suficientemente pequeño como para que los resultados obtenidos sean representativos. Las velocidades de portadora han sido establecidas en 10 7 células/segundo (alrededor de unos 4.2 Gbps). Como excepción nos encontramos con la portadora que llega hasta los sumideros ATM. Con el fin de que el llenado de los búferes fuera más fácil se ha establecido este valor a 4.5x10 6 (aproximadamente 1.9 Gbps). Se realizarán todas las simulaciones a una duración máxima de 4.3 milisegundos simulados. Consideramos que es tiempo suficiente como para obtener resultados representativos teniendo en cuenta el tráfico de fondo generado. 81

82 12.2. Comportamiento del tráfico de tramas con relación al umbral. En este apartado vamos a fijarnos primeramente en el efecto del umbral en el tráfico de tramas. Para ello hemos realizado múltiples simulaciones para distintos valores de umbral y distintos valores de tamaños de trama. Nuestro propósito es comprobar primeramente que el tráfico EAAL mejora con respecto al AAL en el sentido de que llegan más tramas correctas EAAL al sumidero destino que con AAL evitando así las retransmisiones de protocolos superiores al TAP como, por ejemplo, TCP/IP. Así mismo queremos también demostrar que el valor del umbral debe ser establecido en relación al tamaño medio de las tramas EAAL que circulan por un conmutador en congestión. Las conexiones AAL y EAAL que intervendrán en la topología presentan la siguiente configuración: Conexion Nombre: coneaal Destinos: S_EAAL_1 VPI VCI: 1 1 Inicio: 0.0 Duracion: 4.0 TipoTrafico: EAAL Tamaño: 16 GoS: 9 TipoCos: UBR PCR: Conexion Nombre: conaal Destinos: S_AAL_1 VPI VCI: 1 1 Inicio: 0.0 Duracion: 4.0 TipoTrafico: AAL Tamaño: 16 TipoCos: UBR PCR: Cuadro 22.1: Conexiones de tramas programadas. Es necesario señalar que se ha provisto a las conexiones EAAL de un tamaño suficiente de GoS para suministrar todas las retransmisiones que sean necesarias. Así mismo la memoria DMTE es suficientemente grande como para contener las tramas solicitadas en el grado GoS. En posteriores apartados veremos el efecto de estos valores sobre el tráfico. Primeramente nos centraremos sobre el tráfico EAAL y veremos el número de tramas que llegan correctamente al sumidero S_EAAL_1 que es el destino de las tramas mandadas por la fuente F_EAAL_1. 82

83 Tramas recibidas Tamaño trama (células) % 80% 90% 95% 99% 100% Tamaño del umbral (con relación al tamaño del buffer) 70% 80% 90% 95% 99% 100% Gráfica 22.2: Comparación de las tramas EAAL llegadas correctamente al sumidero S_EAAL_1. De esta gráfica deducimos varias cosas: 1- La primera de ellas es que con valores de umbral inferiores a 100% (donde no actuará éste y por lo tanto no habrán solicitudes de retransmisión) todas las tramas enviadas llegarán a su destino correctamente. La fluctuación que se observa en los valores se debe a las tramas in-flight, es decir, a las tramas que se encuentran en los cables y no han llegado a un conmutador. Este hecho se ha deducido estudiando el fichero FIS de cada una de las simulaciones 2- Cuando no actúan las retransmisiones, es decir, cuando el valor del umbral está al 100% y EPDR no actúa, hay tramas que se pierden debido a las congestiones y que deberán ser recuperadas por protocolos superiores. En la gráfica 4 se demuestra cómo aun sin actuar el EPDR el tráfico mejora considerablemente con tramas EAAL con respecto a las AAL. En la siguiente gráfica observamos los mismos valores anteriores pero traducidos a número de células que llegan al sumidero S_ EAAL_1. De esta forma observaremos más fácilmente el porcentaje de información que llega a dicho sumidero. 83

84 Bytes recibidos % 80% 90% 95% % 100% Tamaño del umbral (con relación al tamaño del buffer) 70% 80% 90% 95% 99% 100% Gráfica 22.3: Comparación de los bytes totales llegados correctamente al sumidero S_EAAL_1. En esta gráfica podemos observar que para mayor longitud de trama se observa más información in-flight observándose las fluctuaciones más elevadas en porcentajes elevados del umbral. Esto es consecuencia del tamaño de la trama, cuanto más grande sea la trama mayor información contendrá y más células se encontrarán in-flight. Observamos de nuevo el menor número de información recibida por el sumidero cuando no actúa el algoritmo EPDR. En la anterior gráfica hemos visto como el tráfico se degrada cuando el algoritmo EPDR no actúa en un conmutador activo que despacha tramas EAAL. En la gráfica que a continuación mostramos comparamos el rendimiento de esta conexión EAAL con la conexión AAL que circula paralela a ella. La conexión AAL atraviesa por elementos idénticos a la EAAL y con tráfico de fondo también idéntico. Además su configuración es igual a la EAAL con la salvedad, claro está, de que no tiene GoS. 84

85 Tramas recibidas EAAL EAAL Correctas Corruptas AAL Correctas Tipo de trama y corrección a su llegada al sumidero. AAL Corruptas Tamaño trama (células) EAAL Correctas EAAL Corruptas AAL Correctas AAL Corruptas Gráfica 22.4: Tramas EAAL y AAL llegadas correctas y corruptas a los sumideros S_EAAL_1 y S_AAL_1 respectivamente con el umbral al 100%. Esta gráfica es muy representativa. Se puede observar cómo a pesar de no actuar el sistema de control del búfer ni el sistema de retransmisiones, el tráfico EAAL se ve mejorado sensiblemente con respecto al AAL en el sentido de que las tramas corruptas que circulan por la red son nulas. Esto es debido a que el conmutador CA_9 desecha todas las tramas no correctas procedentes de conexiones EAAL. Esta labor la realiza el agente CoSa en los conmutadores activos. Como consecuencia, mientras que las tramas AAL corruptas siguen circulando por la red ocupando ancho de banda de forma innecesaria, las tramas corruptas de conexiones EAAL desaparecerán en el siguiente conmutador activo por el que vayan a cruzar. Además se puede ver que las tramas recibidas correctamente con tráfico EAAL son superiores a las recibidas con tráfico AAL. Esto no es debido a las retransmisiones ya que con el umbral al 100% un conmutador no realiza peticiones de retransmisión. El motivo de esta mejora es debido al agente CoSa junto con la forma del tráfico de fondo. Éste agente retiene las tramas EAAL hasta que están completas antes de enviarlas a que sean conmutadas. En un tráfico de fondo a ráfagas, como el diseñado para esta topología, el hecho de inyectar la trama entera al buffer provoca que sea más probable que todas las células de la trama sufran la misma suerte. Por lo tanto, como el búfer está menos tiempo lleno que semi-lleno congestionarán menos tramas. En el caso de las tramas AAL las células pertenecientes a éstas son conmutadas e introducidas en el 85

86 búfer al mismo ritmo al que llegan, sin reensamblado. Por tanto, al tardar más tiempo una trama en ser conmutada, hay más probabilidades de que coincida su almacenamiento en el búfer con una etapa de congestión de éste. En anteriores párrafos hemos visto cómo el nivel del umbral no es decisivo a la hora del número de tramas que llegan a un sumidero destino, a excepción de un umbral al 100% por razones ya explicadas. Sin embargo hemos apuntado el hecho de que se producen congestiones y que se pierden células pertenecientes a tramas. En posteriores gráficas veremos en qué influye el umbral en la existencia de congestiones y en las peticiones de retransmisión de tramas Células descartadas Tam. trama % 80% 90% 16 Tamaño del umbral (con relación al tamaño del buffer) 95% 99% 100% 64 70% 80% 90% 95% 99% 100% Gráfica 22.5: Comparación de las células descartadas en el conmutador CA_9 en función del tamaño de trama. En la anterior gráfica se muestran las células que se descartan en el conmutador CA_9 como consecuencia de descartes de células realizados por el EPDR o por congestiones. Vemos cómo a medida que aumentamos el porcentaje del umbral disminuyen el número de células descartadas pero sólo hasta un cierto valor. En la gráfica se observa cómo en el porcentaje del 99% en un búfer de 1000 células el número de células descartadas vuelve a crecer. Hay varias razones para este comportamiento: 1- Según el comportamiento del EPDR si al ir a conmutar la primera célula de una trama EAAL se observa que el nivel de llenado del búfer ha sobrepasado al umbral, esta célula 86

87 se descarta, junto con las células pertenecientes a la misma trama que se conmuten con posterioridad. Por lo tanto, a menor nivel de umbral es más probable que se descarte una trama. 2- El hecho del repunte de tramas descartadas en un umbral con porcentaje al 99% lo explicaremos mejor a partir de la siguiente gráfica: Gráfica 22.6: Comparación de los niveles de llenado del búfer del conmutador CA_6 en umbrales al 95% y al 99%. En la gráfica se ve cómo para valores elevados de llenado del buffer se producen muchas más congestiones con el búfer al 99% que con el búfer al 95%. Analizando el FIS vemos que esto se debe concretamente a que se intenta introducir una trama en el búfer que no va a caber. Según el algoritmo EPDR, cuando se conmuta la primera célula de una trama se comprueba primeramente si cabe según el umbral, si es así se introduce, si no se descarta junto con las células pertenecientes a la misma trama que aparezcan a continuación. El problema surge cuando el espacio entre el umbral y el búfer está muy cercano al tamaño de trama. En este caso será más probable que la trama comience a introducirse por debajo del umbral, que lo sobrepase y que finalmente haya que descartar alguna de sus células al no caber físicamente el búfer. El hecho de que se descarten menos células (con un umbral al 99%) a medida que disminuimos el tamaño de trama corrobora nuestra explicación. Los hechos descritos anteriormente pueden verse en la gráfica de retransmisiones solicitadas que vemos a continuación: 87

88 Retrans. Solicitadas Tamaño trama (células) % 80% 90% 95% 99% 100% Tamaño del umbral (con relación al tamaño del buffer) 64 70% 80% 90% 95% 99% 100% Gráfica 22.7: Comparación de las retransmisiones solicitadas por el conmutador CA_6 al conmutador CA_4. En esta gráfica anterior se ve más claramente el efecto del umbral sobre el descarte de tramas. Las diferencias tan grandes de descartes entre tamaños de tramas se deben a que se envían más tramas de 16 células que de 32 y que de 64; sin embargo los bytes mandados por la fuente F_EAAL_1 son los mismos. Así mismo se ve que se descartan más tramas de 32 que de 64 células con el umbral al 99%. Este hecho se debe a que las retransmisiones de tramas de 32 células son más rápidas al tenerse que enviar menor número de células Influencia del EPDR en la fragmentación Un hecho importante y nocivo para las redes que pretende evitar el EPDR es la fragmentación de tramas, es decir, se pretende evitar que continúen tramas EAAL a las que se les ha congestionado alguna célula y por lo tanto ha tenido que ser descartada. En este apartado pretendemos estudiar cómo afecta el umbral al número de tramas fragmentadas que, a pesar del EPDR, continúan hacia el sumidero destino. Para estudiar este hecho hemos de modificar la 88

89 topología base para evitar que el último conmutador, el agente CoSa del CA_9, elimine aquellas tramas que detecta fragmentadas; por ello hemos sustituido este conmutador por un conmutador no activo, el CNA_1 que comparte la misma configuración en los elementos comunes. La nueva topología se muestra en la figura Figura 22.8: Topología mixta con conmutadores no activos finales. Para estudiar el efecto de la fragmentación nos concentraremos en simulaciones creadas sobre tramas de tamaño fijo de 32 células. Como elementos cambiantes tendremos el porcentaje del umbral. Estudiaremos la fragmentación de las EAAL en contraste con las conexiones AAL las cuales no se beneficiarán directamente de los mecanismos del EPDR. Podemos ver en la gráfica 22.9 los resultados obtenidos. Observamos que las tramas AAL se fragmentan a un ritmo constante independientemente del valor del umbral. Esto es lógico si tenemos en cuenta que el algoritmo EPDR no actúa sobre conexiones AAL sino únicamente sobre las conexiones EAAL por lo que el valor del umbral para las primeras no tiene ninguna influencia. Por otro lado siempre llegan más tramas correctas que incorrectas siendo las segundas aproximadamente el 43% de las tramas totales recibidas por el sumidero. En cuanto a la fragmentación de las tramas EAAL hemos obtenido una gráfica muy parecida a anteriores gráficas. Al igual que con las células descartadas y las peticiones de retransmisiones, las tramas fragmentadas descienden a medida que aumenta el umbral, a excepción del fenómeno ya conocido del repunte en el porcentaje al 99%. La explicación se debe a que cuando por acción del umbral se descarta una trama, si la célula EOM de dicha trama cabe en el búfer, ésta se introduce aunque se haya descartado todas las células de información de la trama. Sin embargo el repunte no aparece tan pronunciado como en anteriores gráficos. Esto es debido a la misma circunstancia anterior, a que le EOM sólo se introduce en el caso de que haya 89

90 espacio en el buffer. Por eso mismo es mucho menos probable en un búfer al 99% (casi al 100%) de su capacidad quepa la célula EOM. Tramas recibidas EAAL Correctas 70% 80% 90% 95% 99% 100% AAL Corruptas Tipo Trama AAL Corruptas AAL Correctas EAAL Correctas EAALCorrup tas Tamaño del umbral (con relación al tamaño del buffer) 70% 80% 90% 95% 99% 100% AAL Corruptas AAL Correctas EAAL Correctas EAALCorruptas Gráfica 22.9: Proporción entre las tramas llegadas correcta e incorrectamente al sumidero S_EAAL_1 para tramas de 32 células con distintos valores de umbral. Para finalizar este apartado vamos a estudiar el efecto de los conmutadores activos, para un umbral al 100% en conexiones EAAL y AAL. En la gráfica se pueden observar los resultados de este caso. De esta gráfica se obtienen dos conclusiones: 1- Las conexiones EAAL mejoran con respecto a las AAL, aun sin el mecanismo de retransmisiones. 2- Sin la actuación del EPDR se pierden muchas más tramas completas que con conexiones AAL. Este hecho destaca más con conexiones de 64 células. La explicación, que tiene que ver con al agente CoSa junto con la forma del tráfico de fondo, se dio ya en el anterior punto. 90

91 Tamaño trama (células) Tramas recibidas EAAL Bien EAAL Mal AAL Bien AAL Mal Total EAAL Tipo de trama y corrección a su llegada al sumidero. Total AAL 64 EAAL Bien EAAL Mal AAL Bien AAL Mal Total EAAL Total AAL Gráfica 22.10: Diferencia entre tramas correcta e incorrectamente llegadas según el tipo de conexión con un umbral al 100% Influencia del tamaño del búfer del conmutador congestionado En este punto estudiaremos la influencia del tamaño del búfer sobre las conexiones EAAL en congestión. Partiremos de la topología descrita en la figura 22.1 y estudiaremos algunas simulaciones con distintos tamaños de búfer y de umbral. El tamaño de trama lo hacemos esta vez constante al valor de 32 células. Para cada valor diferente de capacidad de búfer se ha modificado el tráfico de fondo para que el patrón de llenado sea igual al mostrado en la gráfica Para ello se aumentando o disminuido, según sea el caso, la velocidad de envío del tráfico ATM de fondo así como velocidad de portadora de salida del puerto al que está conectado el sumidero ATM. A priori parece obvio que con valores mayores de búfer el tráfico, tanto de células ATM como de tramas AAL y EAAL, se verá favorecido y no tan afectado por las temidas congestiones. En la gráfica se pueden observar los datos obtenidos en las simulaciones. 91

92 Retrans. solicitadas Tamaño del búfer % 80% 90% 95% 99% % Tamaño del umbral (con relación al tamaño del buffer) 70% 80% 90% 95% 99% 100% Gráfica 22.11: Retransmisiones solicitadas con distintos valores de búfer(con tráfico de fondo revisado) y de umbral para tramas de 32 células. Vemos que el efecto repunte en el umbral al 99% disminuye a medida que aumentamos el tamaño del búfer hasta que llegamos a un punto que desaparece. Sin embargo es de prever que si subimos el umbral por encima del 99% el efecto repunte volverá a aparecer. Por tanto llegamos a la conclusión de que hay que encontrar un equilibro entre el tamaño del búfer y el valor del umbral teniendo en cuenta el tamaño medio de trama. Para el algoritmo EPDR estos parecen ser los factores más importantes Influencia del grado de GoS de las conexiones privilegiadas. En este apartado estudiaremos la influencia del grado de GoS en el rendimiento de las conexiones EAAL. Recordemos que el grado de GoS es un parámetro que se establece para las conexiones EAAL y que se negocia con los conmutadores activos durante el transcurso del 92

93 proceso de establecimiento de conexiones. Este parámetro representa el número de tramas EAAL que se pide a los conmutadores guarden en su memoria DMTE para poder servir peticiones de retransmisión. En un principio se puede pensar que cuanto mayor sea le valor de la DMTE mejor será el rendimiento de la conexión. Veremos con la siguiente gráfica si eso es cierto. Las simulaciones en las que se basa esta gráfica han sido realizadas sobre las tramas que más retransmisiones provocan en el conmutador CA_6, las de 16 células. La topología de la que partimos es idéntica a la presentada en la figura 1. Vamos a estudiar el número de retransmisiones no servidas para distintos grados de GoS para la conexión EAAL en función del valor del umbral. Por retransmisiones no servidas entendemos aquellas que pide el conmutador CA_6 y que no pueden servir ni el conmutador CA_4 ni el CA_1 por no existir ya copia de la trama en la DMTE. Este hecho sucede cuando la trama requerida ha sido sustituida por una más reciente al no haber espacio libre en la DMTE. En la gráfica se presentan los resultados obtenidos Grado de GoS Retrans. no servidas % 80% 90% 95% 99% 9 Tamaño del umbral (con relación al tamaño del buffer) 70% 80% 90% 95% 99% Gráfica 22.12: Número de retransmisiones no servidas en relación con el umbral para distintos valores de GoS. 93

94 Vemos en esta gráfica cómo el número de tramas no servidas desciende rápidamente a medida que aumentamos el grado de GoS. Todas estas tramas no servidas se perderán y tendrán que ser retransmitidas por los protocolos superiores del modelo ATM si se las quiere recuperar. También se muestra cómo llega un momento que aunque aumentemos el grado de GoS no mejora el rendimiento ya que se sirven todas aquellas peticiones de retransmisión que se solicitan mientras que éstas están ocupando espacio en la DMTE de manera innecesaria. Por tanto hay que llegar a un compromiso entre las congestiones esperadas que se produzcan para una conexión y el grado de GoS solicitado sin aumentar éste de manera innecesaria. Vemos también cómo sólo se pierden tramas por retransmisiones no servidas en porcentajes de umbral del 70% y de 80%. El descenso tan brusco se debe a que se pierden menos tramas y por tanto se transmiten menos peticiones de retransmisión. Esto provoca que no aumente el tráfico EAAL con retransmisiones y, consecuentemente, que no se produzcan congestiones por este tráfico añadido, un hecho éste que hay que evitar a la hora de diseñar una red con conmutadores activos. Así pues hemos visto que un exceso de peticiones de retransmisión puede provocar un aumento exponencial en el tráfico existente entre dos conmutadores. Una forma de solucionar este hecho perjudicial podría ser la de distanciar los conmutadores activos entre si. Cuanto mayor sea la distancia entre dos conmutadores activos más tiempo pasará desde una congestión y su consecuente petición de retransmisión hasta el momento en el que esta petición es atendida y servida. Esto sería beneficioso para el tráfico en el sentido de que habría dado tiempo para que actuaran en los conmutadores los mecanismos de prevención y evitación de congestión y, por tanto, bajase el nivel de llenado del búfer antes de que llegara la trama congestionada. En las siguientes gráficas vamos a estudiar la anterior hipótesis. Para ello hemos construido una topología mixta en la que el conmutador anterior al conmutador congestionado lo hemos sustituido por un conmutador no activo por lo que la petición de retransmisión la tendrá que servir el primer conmutador. La nueva topología, idéntica a la de la gráfica anterior salvo por la diferencia anteriormente indicada, se muestra en la figura

95 Figura 22.13: Topología mixta con retransmisiones de largo recorrido La gráfica resultante de hacer la simulación de la topología anterior para diferentes tamaños de GoS y de umbral es un poco sorprendente. 95

UNI (User to Network Interface). La interfaz UNI conecta sistemas finales ATM (tales como servidores y routers) a un conmutador ATM.

UNI (User to Network Interface). La interfaz UNI conecta sistemas finales ATM (tales como servidores y routers) a un conmutador ATM. Lección 2: Redes ATM Para la transmisión, ATM emplea celdas de tamaño fijo de 53 bytes que resulta de un compromiso entre los requisitos de las aplicaciones de voz (paquetes de tamaño reducido son preferibles

Más detalles

CAPÍTULO 1 FUNDAMENTOS DE LA TECNOLOGÍA ATM 1.1. INTRODUCCIÓN

CAPÍTULO 1 FUNDAMENTOS DE LA TECNOLOGÍA ATM 1.1. INTRODUCCIÓN CAPÍTULO 1 FUNDAMENTOS DE LA TECNOLOGÍA ATM 1.1. INTRODUCCIÓN El Modo de Transferencia Asíncrono (ATM) es la base de un estándar internacional propuesto como un sistema de conmutación de paquetes para

Más detalles

Calidad de Servicio en redes Frame Relay y ATM. Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga

Calidad de Servicio en redes Frame Relay y ATM. Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga Calidad de Servicio en redes Frame Relay y ATM Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga Evolución redes WAN de paquetes Redes X.25 Año: 1976 Primeras redes de cx paquetes Redes Frame Relay Redes

Más detalles

UNLaM. ATM-Modo de Transferencia asícrono 1) ARQUITECTURA DE PROTOCOLOS

UNLaM. ATM-Modo de Transferencia asícrono 1) ARQUITECTURA DE PROTOCOLOS E1 modo de transferencia asíncrono (ATM, Asynchronous Transfer Mode), también conocido como retransmisión de celdas, aprovecha las características de fiabilidad y fidelidad de los servicios digitales modernos

Más detalles

REDES ATM. Conceptos, Circuitos, Arquitectura y conmutadores.

REDES ATM. Conceptos, Circuitos, Arquitectura y conmutadores. REDES ATM. Conceptos, Circuitos, Arquitectura y conmutadores. 1 QUÉ ES ATM? ATM son las siglas de Asynchronous Transfer Model, o lo que es lo mismo, modo de transaferencia asincrona, diseñado por el foro

Más detalles

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de

En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de En este capítulo se proporciona una visión general de las redes de computadores. Así, se presenta una descripción general de las comunicaciones de datos y la tipología de redes que se emplean. Además este

Más detalles

Tipos de Redes: Topologías de red: Según el tamaño: Según su tecnología de transmisión: Según en tipo de transferencia de datos:

Tipos de Redes: Topologías de red: Según el tamaño: Según su tecnología de transmisión: Según en tipo de transferencia de datos: Tipos de Redes: Según el tamaño: -LAN (red de área local): de 10 metros a 1 kilómetro, suelen usar broatcast y su velocidad va de 10 a 100 MBps. -MAN (red de área metropolitana): tamaño máximo 10 kilómetros.

Más detalles

ALB-W-000003sp WHITE PAPER. White Paper. Medida del throughput con transmisiones sobre TCP. Septiembre 2009. Medida del throughput sobre TCP

ALB-W-000003sp WHITE PAPER. White Paper. Medida del throughput con transmisiones sobre TCP. Septiembre 2009. Medida del throughput sobre TCP White Paper Medida del throughput con transmisiones sobre TCP Septiembre 2009 A la hora de medir la tasa máxima de transmisión que puede ofrecer un enlace WiMAX se suele recurrir a herramientas similares

Más detalles

Componentes de la Ingeniería de Tráfico (Recomendaciones ITU-T) Jhon Jairo Padilla Aguilar, PhD.

Componentes de la Ingeniería de Tráfico (Recomendaciones ITU-T) Jhon Jairo Padilla Aguilar, PhD. Componentes de la Ingeniería de Tráfico (Recomendaciones ITU-T) Jhon Jairo Padilla Aguilar, PhD. Recomendaciones de la ITU-T ITU- International Telecommunications Union Las recomendaciones de la ITU-T

Más detalles

Tema 28. Redes de Banda Ancha. XDSI, ADSL, FRAME RELAY, ATM

Tema 28. Redes de Banda Ancha. XDSI, ADSL, FRAME RELAY, ATM Tema 28. Redes de Banda Ancha. XDSI, ADSL, FRAME RELAY, ATM Introducción... 1 Tecnologías de redes de banda ancha... 2 Redes ETHERNET de banda ancha... 3 XDSL Línea de abonado digital-... 4 ADSL - Línea

Más detalles

WAN y Enrutamiento WAN

WAN y Enrutamiento WAN WAN y Enrutamiento WAN El asunto clave que separa a las tecnologías WAN de las LAN es la capacidad de crecimiento, no tanto la distancia entre computadoras Para crecer, la WAN consta de dispositivos electrónicos

Más detalles

ATM. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Redes de Banda Ancha 5º Ingeniería de Telecomunicación

ATM. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Redes de Banda Ancha 5º Ingeniería de Telecomunicación ATM Area de Ingeniería Telemática http://www.tlm.unavarra.es Redes de Banda Ancha 5º Ingeniería de Telecomunicación ATM ATM = Asynchronous Transfer Mode Estándar de la ITU-T y el ATM Forum Años 80 Seleccionada

Más detalles

Redes de comunicación

Redes de comunicación Redes de comunicación Conmutación de circuitos Conmutación de paquetes Dpt. Arquitectura de Computadores 1 Redes conmutadas Conmutación (nodos) de los datos que se reciben de una estación emisora hasta

Más detalles

UNLaM FRAME RELAY 1) FUNDAMENTOS :

UNLaM FRAME RELAY 1) FUNDAMENTOS : La técnica de retransmisión de tramas ( Frame relay ), al igual que ATM, se diseñó para proporcionar un esquema de transmisión más eficiente que el de X.25. Tanto las normalizaciones como los productos

Más detalles

Fibra Óptica Actualidad y futuro de las redes ópticas

Fibra Óptica Actualidad y futuro de las redes ópticas Fibra Óptica Actualidad y futuro de las redes ópticas Francisco Ramos Pascual. Doctor Ingeniero de Telecomunicación. Profesor Titular de Escuela Universitaria. Universidad Politécnica de Valencia Si bien

Más detalles

Redes LAN y WAN UNIDAD. Redes WAN. Routing. Clase 3 Clase 4 Clase 5 Clase 6

Redes LAN y WAN UNIDAD. Redes WAN. Routing. Clase 3 Clase 4 Clase 5 Clase 6 Redes LAN y WAN UNIDAD 2 Redes WAN. Routing Clase 3 Clase 4 Clase 5 Clase 6 Exposición 2.1. Presentación Una red de área amplia o WAN (Wide Area Network) se extiende sobre un área geográfica extensa, a

Más detalles

Modo de transferencia asíncrono. Ruteo IP y Tecnologías de Transporte Instituto de Ingeniería Eléctrica, Universidad de la República

Modo de transferencia asíncrono. Ruteo IP y Tecnologías de Transporte Instituto de Ingeniería Eléctrica, Universidad de la República ATM Modo de transferencia asíncrono 1 Introducción Capa Física Capa ATM Capa AAL Plano de Control ATM Agenda Plano de Gestión ATM Calidad de Servicio ATM Aplicaciones Futuro ATM 2 Qué es ATM? I.150: ATM

Más detalles

ATM Traffic Management

ATM Traffic Management ATM Traffic Management Introducción a la categoría de servicio VBR-rt (velocidad de bits variable en tiempo real) para VC de ATM Traducción por computadora Contenidos Introducción Requisitos previos Requisitos

Más detalles

Las Redes IP; Conceptos básicos

Las Redes IP; Conceptos básicos WHITE PAPER Las redes IP: Conceptos básicos 0 Índice 1.- Introducción... 2 2.- Comunicación de redes, conceptos básicos... 2 3.- Fundamentos de transmisión... 4 4.- Infraestructura de la red de área local

Más detalles

ARQUITECTURA DE REDES Curso 2011/12 Bloque 2 EJERCICIOS UNIDADES III y IV

ARQUITECTURA DE REDES Curso 2011/12 Bloque 2 EJERCICIOS UNIDADES III y IV ARQUITECTURA DE REDES Curso 2011/12 Bloque 2 EJERCICIOS UNIDADES III y IV Parte 2A. Test P1. Respecto a la Red Telefónica, cuál de las siguientes afirmaciones es FALSA? a) Presenta una topología jerárquica,

Más detalles

UNIDAD 1.1 - MODELO OSI/ISO

UNIDAD 1.1 - MODELO OSI/ISO UNIDAD 1.1 - MODELO OSI/ISO El modelo de referencia OSI es el modelo principal para las comunicaciones por red. Aunque existen otros modelos, en la actualidad la mayoría de los fabricantes de redes relacionan

Más detalles

1. PARAMETROS DE CALIDAD DE SERVICIO. -PERDIDAS DE PAQUETES EN LOS ROUTERS: Vía TCP son recuperables, pero las retransmisiones TCP son

1. PARAMETROS DE CALIDAD DE SERVICIO. -PERDIDAS DE PAQUETES EN LOS ROUTERS: Vía TCP son recuperables, pero las retransmisiones TCP son TEMA 6: APLICACIONES MULTIMEDIA EN TIEMPO REAL Internet es una red de computadoras TCP/IP que basa su funcionamiento en la tecnología de conmutación de paquetes mediante un servicio no orientado a conexión.

Más detalles

Fundamentos de Redes de Computadoras

Fundamentos de Redes de Computadoras Fundamentos de Redes de Computadoras Modulo III: Fundamentos de Redes de Area Extendida (WAN) Objetivos Redes conmutadas Circuito Paquetes Conmutación por paquetes Datagrama Circuito virtual Frame Relay

Más detalles

GENERALIDADES DE LA COMUNICACIÓN DE DATOS

GENERALIDADES DE LA COMUNICACIÓN DE DATOS Comunicaciones I Capítulo 1 GENERALIDADES DE LA COMUNICACIÓN DE DATOS 1 El Sistema de Comunicación Sistema de comunicación: Lleva a cabo el intercambio de información entre dos entes ubicados en los extremos

Más detalles

TEMA 12 RETRANSMISIÓN DE TRAMAS. FRAME RELAY.

TEMA 12 RETRANSMISIÓN DE TRAMAS. FRAME RELAY. TEMA 12 RETRANSMISIÓN DE TRAMAS. FRAME RELAY. 12.1. Redes X.25 Es una interfaz entre estación y red de conmutación de paquetes, tambien se utiliza para interaccionar con redes RDSI. Creado en 1976 y modificado

Más detalles

5 Compresión de Cabeceras de Van Jacobson

5 Compresión de Cabeceras de Van Jacobson 5 Compresión de Cabeceras de Van Jacobson 5.1 INTRODUCCIÓN El acceso a servicios de Internet a través de líneas de baja velocidad tanto alámbricas como inalámbricas pone de manifiesto el hecho de la gran

Más detalles

Ejercicios Tema 1 1.- Supongamos que hay exactamente un switch de paquetes entre un host que envía y un host que recibe. Las tasas de transmisión entre el host que envía y el que recibe son R 1 y R 2 respectivamente.

Más detalles

Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet

Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet 7.5 Efectos de los dispositivos de Capa 2 sobre el flujo de datos 7.5.1 Segmentación de la LAN Ethernet 1 2 3 3 4 Hay dos motivos fundamentales para dividir una LAN en segmentos. El primer motivo es aislar

Más detalles

Problemas de Arquitectura de Redes, Sistemas y Servicios 2 o Grado en Ingeniería en Tecnologías de Telecomunicación Conjunto de problemas 6

Problemas de Arquitectura de Redes, Sistemas y Servicios 2 o Grado en Ingeniería en Tecnologías de Telecomunicación Conjunto de problemas 6 Problemas de Arquitectura de Redes, Sistemas y Servicios 2 o Grado en Ingeniería en Tecnologías de Telecomunicación Conjunto de problemas 6 Problema 6.1: Se pretende utilizar una red de area local de 10Mbps

Más detalles

INTRODUCCIÓN Videoconferencia sobre Frame Relay

INTRODUCCIÓN Videoconferencia sobre Frame Relay INTRODUCCIÓN Videoconferencia sobre Frame Relay Homero Andrango María Fernanda Jerez Patricia Yacelga Se denomina videoconferencia al sistema que permite a un grupo de personas ubicadas en lugares distantes

Más detalles

Transporte de audio sobre redes IP

Transporte de audio sobre redes IP REPORTAJE El objeto del artículo es evaluar la viabilidad de utilizar sistemas que permitan el transporte de audio, con la calidad necesaria en las emisoras de radio y TV, a través de redes IP (redes corporativas

Más detalles

TRANSMISION DE DATOS Intercambio de datos (en forma de ceros y unos) entre dos dispositivos a través de un medio de Tx.

TRANSMISION DE DATOS Intercambio de datos (en forma de ceros y unos) entre dos dispositivos a través de un medio de Tx. ASIGNATURA: REDES DE COMPUTADORE I Lectura 1. TEMAS: REPASO FUNDAMENTOS DE LAS COMUNICACIONES Transmisión de datos Estándares y organizaciones de normalización. FUNDAMENTOS DE LA INTERCONECTIVAD DE REDES.

Más detalles

CCNA Voice. Calidad de Servicio

CCNA Voice. Calidad de Servicio CCNA Voice Calidad de Servicio Contenido Definición de QoS 1 5 Requisitos de QoS para VoIP Ancho de Banda 2 6 Requisitos de QoS para tráfico de datos Latencia o Retardo 3 7 AutoQoS Pérdida de Paquetes

Más detalles

Redes de datos. Tema 1. Introducción

Redes de datos. Tema 1. Introducción Redes de datos Tema 1 Introducción Diapositiva 1 6.263: Redes de datos Fundamentos del análisis y el diseño de redes: Arquitectura: Capas Topología Protocolos: Punto a punto Acceso múltiple Extremo a extremo

Más detalles

Centro de Supercomputación de Galicia

Centro de Supercomputación de Galicia RECETGA: EVOLUCIÓN HISTÓRICA La puesta en marcha del Centro de Supercomputación de Galicia permitió, además de ofrecer servicios de cálculo de altas prestaciones, la conexión de los siete campus de las

Más detalles

Conmutación y Re-envío Parte 2 Switching y Forwarding

Conmutación y Re-envío Parte 2 Switching y Forwarding Conmutación y Re-envío Parte 2 Switching y Forwarding Contenido Conmutación de Celdas Segmentación y Re-ensamble ELO309 1 Conmutación de Celdas (Asynchronous Transmission mode, ATM) Orientada a la conexión.

Más detalles

El modelo OSI. Introducción. Conceptos generales

El modelo OSI. Introducción. Conceptos generales El modelo OSI Introducción En un principio, los computadores eran elementos aislados, constituyendo cada uno de ellos una estación de trabajo independiente, una especie de "isla informática". Cada computador

Más detalles

TEMA 1. Introducción

TEMA 1. Introducción TEMA 1 Introducción Contenidos: Visión estructurada de los sistemas de transmisión de datos. Arquitectura de protocolos. 1 Modelo simplificado de comunicaciones Fuente Transmisor Sistema de transmisión

Más detalles

Lección 1: TÉCNICAS PARA MEJORAR LA CALIDAD DE SERVICIO

Lección 1: TÉCNICAS PARA MEJORAR LA CALIDAD DE SERVICIO Lección 1: TÉCNICAS PARA MEJORAR LA CALIDAD DE SERVICIO En esta sección, se describe algunas técnicas que se pueden utilizar para mejorar la calidad de servicio. Se van para describir brevemente cuatro

Más detalles

EXÁMEN ASIGNATURA REDES CURSO: CUARTO INGENIERÍA INFORMÁTICA CONVOCATORIA SEPTIEMBRE 1997

EXÁMEN ASIGNATURA REDES CURSO: CUARTO INGENIERÍA INFORMÁTICA CONVOCATORIA SEPTIEMBRE 1997 Parte 1. Preguntas. EXÁMEN ASIGNATURA REDES CURSO: CUARTO INGENIERÍA INFORMÁTICA CONVOCATORIA SEPTIEMBRE 1997 Esta parte debe realizarla el alumno sin material de consulta. Puede utilizar una calculadora

Más detalles

1º INTRODUCCIÓN La comunicación es el intercambio de información entre dos o más individuos o entidades de un proceso.

1º INTRODUCCIÓN La comunicación es el intercambio de información entre dos o más individuos o entidades de un proceso. TECNOLOGIA DE LAS INFRAESTRUCTURAS DE LAS COMUNICACIONES 1º INTRODUCCIÓN La comunicación es el intercambio de información entre dos o más individuos o entidades de un proceso. Las Infraestructuras de las

Más detalles

Capa de Red. Arquitectura de circuitos virtuales

Capa de Red. Arquitectura de circuitos virtuales Capa de Red Arquitectura de circuitos virtuales 1 Redes de circuitos virtuales Antes de transferir datos, se debe establecer un circuito virtual (CV) Administrativamente o dinámicamente En el caso dinámico,

Más detalles

Redes WAN. Introducción a las redes WAN. Esteban De La Fuente Rubio esteban@delaf.cl L A TEX. 12 abr 2011. Universidad Andrés Bello

Redes WAN. Introducción a las redes WAN. Esteban De La Fuente Rubio esteban@delaf.cl L A TEX. 12 abr 2011. Universidad Andrés Bello Introducción a las redes WAN esteban@delaf.cl L A TEX Universidad Andrés Bello 12 abr 2011 Tabla de contenidos 1 En las empresas En los hogares Modelo 3 capas Arquitectura empresarial CISCO 2 Capa física

Más detalles

Tema 5.- Redes de Área extensa

Tema 5.- Redes de Área extensa Tema 5.- Redes de Área extensa En el tema 2 se habló de la red de teléfonos (RTC) como un ejemplo de red de área extensa o WAN. Sin embargo, se vio que la capacidad de dicha red para transmitir datos está

Más detalles

Redes Mg. Gabriel H. Tolosa

Redes Mg. Gabriel H. Tolosa Redes Mg. Gabriel H. Tolosa. tolosoft@unlu.edu.ar "There is no reason for any individual to have a computer in his home" Ken Olsen, fundador y CEO de DEC, 1977. Redes Qué es una red? Conjunto de computadoras

Más detalles

FUNDAMENTOS DE REDES CONCEPTOS DE LA CAPA DE RED

FUNDAMENTOS DE REDES CONCEPTOS DE LA CAPA DE RED FUNDAMENTOS DE REDES CONCEPTOS DE LA CAPA DE RED Dolly Gómez Santacruz dolly.gomez@gmail.com CAPA DE RED La capa de red se ocupa de enviar paquetes de un punto a otro, para lo cual utiliza los servicios

Más detalles

Conmutación. Índice. Justificación y Definición. Tipos de Conmutación. Conmutación Telefónica. Red de Conexión y Unidad de Control

Conmutación. Índice. Justificación y Definición. Tipos de Conmutación. Conmutación Telefónica. Red de Conexión y Unidad de Control Conmutación Autor: 1 Índice Justificación y Definición Tipos de Conmutación Conmutación Telefónica Red de Conexión y Unidad de Control Funciones de los equipos de Conmutación Tipos de conmutadores 2 Justificación:

Más detalles

Redes de Computadoras Junio de 2006. Teoría y problemas (75 %)

Redes de Computadoras Junio de 2006. Teoría y problemas (75 %) Redes de Computadoras Junio de 2006 Nombre: DNI: Teoría y problemas (75 %) 1. (1 punto) Suponga una aplicación P2P de compartición de ficheros en la que existe un servidor central que ofrece un servicio

Más detalles

Estructura de buses para control de AGV

Estructura de buses para control de AGV Estructura de buses para control de AGV Con el concepto moderno de sistemas internetworking, se plantea una estructura de control para un vehículo autónomo, considerando al mismo como una celda de proceso

Más detalles

Tecnologías de Redes WAN. Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga

Tecnologías de Redes WAN. Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga Tecnologías de Redes WAN Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga Evolución redes WAN de paquetes Redes X.25 Año: 1976 Primeras redes de cx paquetes Redes Frame Relay Redes ATM Redes MPLS Aparición

Más detalles

Redes de altas prestaciones: Frame Relay. Escuela Superior de Informática (Ciudad Real)

Redes de altas prestaciones: Frame Relay. Escuela Superior de Informática (Ciudad Real) Redes de altas prestaciones: Frame Relay Pablo Gómez G Justicia Escuela Superior de Informática (Ciudad Real) Índice Conceptos previos Introducción Funcionamiento de Frame Relay Niveles Niveles en Frame

Más detalles

Redes de Banda Ancha

Redes de Banda Ancha Redes de Banda Ancha FR: características Diseñada para redes WAN Solo nivel físico y de enlace Solo detección de errores en el nivel de enlace Basada en circuitos virtuales Velocidad: 1,544 Mbps 44,476

Más detalles

ADSL. Indice de Contenidos. Tecnología y Servicios. 8 Mayo 2002. Entorno Regulatorio Tecnología. Servicios del Grupo Telefónica

ADSL. Indice de Contenidos. Tecnología y Servicios. 8 Mayo 2002. Entorno Regulatorio Tecnología. Servicios del Grupo Telefónica ADSL Tecnología y Servicios 8 Mayo 2002 1 Indice de Contenidos Entorno Regulatorio Tecnología Nivel 1: ADSL, PDH y SDH Nivel 2:, AAL Niveles superiores: MPoA, PPPoE, PPPoA Servicios del Grupo Telefónica

Más detalles

Tema 4 Redes de Área Amplia

Tema 4 Redes de Área Amplia Tema 4 Redes de Área Amplia Índice - Introducción - Conmutación de circuitos - Conmutación de paquetes - Comparación de técnicas de conmutación - Encaminamiento - Control de congestión - Las WAN y el modelo

Más detalles

Introducción a redes Ing. Aníbal Coto Cortés

Introducción a redes Ing. Aníbal Coto Cortés Capítulo 5: Ethernet Introducción a redes Ing. Aníbal Coto Cortés 1 Objetivos En este capítulo, aprenderá a: Describir el funcionamiento de las subcapas de Ethernet. Identificar los campos principales

Más detalles

4.2 CARACTERIZACIÓN DE CANALES RADIO MÓVILES

4.2 CARACTERIZACIÓN DE CANALES RADIO MÓVILES 4 Redes Móviles 4.1 INTRODUCCIÓN Los servicios de transmisión de datos a través de redes móviles constituyen uno de los sectores de las telecomunicaciones destinado a experimentar un auge más notable en

Más detalles

Tema 1. Introducción a las redes de comunicaciones.

Tema 1. Introducción a las redes de comunicaciones. Tema 1. Introducción a las redes de comunicaciones. 1.- Cuando se realiza una llamada telefónica local a otra persona, qué tipo de configuración se está utilizando? a) Punto a punto b) Punto a multipunto

Más detalles

MECANISMOS DE PROTECCIÓN Y RESTAURACIÓN

MECANISMOS DE PROTECCIÓN Y RESTAURACIÓN MECANISMOS DE PROTECCIÓN Y RESTAURACIÓN Sistemas de Telecomunicación Alumnos: Pablo Núñez López Alberto Garzón Leo INDICE 1. Índice 2. Introducción y objetivos Definiciones Mecanismos de protección y restauración

Más detalles

3. CONMUTACION Y CONTROL DE LA CONMUTACIÓN

3. CONMUTACION Y CONTROL DE LA CONMUTACIÓN 3. CONMUTACION Y CONTROL DE LA CONMUTACIÓN 3.1 INTRODUCCION 3.1.1 QUE ENTENDEMOS POR CONMUTACIÓN Una respuesta a esta pregunta podría ser la instalación de una conexión entre dos suscriptores de líneas

Más detalles

LA ARQUITECTURA TCP/IP

LA ARQUITECTURA TCP/IP LA ARQUITECTURA TCP/IP Hemos visto ya como el Modelo de Referencia de Interconexión de Sistemas Abiertos, OSI-RM (Open System Interconection- Reference Model) proporcionó a los fabricantes un conjunto

Más detalles

Top-Down Network Design. Tema 13

Top-Down Network Design. Tema 13 Top-Down Network Design Tema 13 Optimización del Diseño de la Red Copyright 2010 Cisco Press & Priscilla Oppenheimer Traducción: Emilio Hernández Adaptado para ISI: Enrique Ostúa. 13-1 INDICE :: Optimización

Más detalles

INGENIERÍA INFORMÁTICA. EXAMEN REDES. Junio 1999. Primera Parte. Esta parte debe realizarse sin material de consulta. Puede utilizar una calculadora.

INGENIERÍA INFORMÁTICA. EXAMEN REDES. Junio 1999. Primera Parte. Esta parte debe realizarse sin material de consulta. Puede utilizar una calculadora. INGENIERÍA INFORMÁTICA EXAMEN REDES. Junio 1999 El examen consta de dos partes. La primera puntúa hasta un máximo de 5,5 puntos, y la segunda hasta 3 puntos. La nota de los ejercicios de clase vale hasta

Más detalles

Tipos de comunicación La comunicación puede ser:

Tipos de comunicación La comunicación puede ser: Unidad 3. Procesos concurrentes 3.3 Semáforos (informática) Un semáforo es una variable especial (o tipo abstracto de datos) que constituye el método clásico para restringir o permitir el acceso a recursos

Más detalles

Redes de Computadoras 3 de Diciembre de 2004. Examen de teoría

Redes de Computadoras 3 de Diciembre de 2004. Examen de teoría Redes de Computadoras 3 de Diciembre de 2004 Nombre: DNI: Examen de teoría V F Verdadero/Falso. Con FDM cada circuito consigue todo el ancho de banda periódicamente durante breves instantes de tiempo (es

Más detalles

QUÉ ES UNA RED DE ÁREA METROPOLITANA?

QUÉ ES UNA RED DE ÁREA METROPOLITANA? QUÉ ES UNA RED DE ÁREA METROPOLITANA? Una red de área metropolitana es una red de alta velocidad (banda ancha) que dando cobertura en un área geográfica extensa, proporciona capacidad de integración de

Más detalles

SWITCH ETHERNET CAPA 2. Justo Ramírez Martínez

SWITCH ETHERNET CAPA 2. Justo Ramírez Martínez SWITCH ETHERNET CAPA 2 Justo Ramírez Martínez ÍNDICE (I) Introducción Ethernet Bridging and Switching Dispositivos de conexión de redes Tipos de dispositivos Dispositivos de conexión de nivel 2 Puentes

Más detalles

Solución del examen de Redes - Segundo parcial - ETSIA - 1 de junio 2007

Solución del examen de Redes - Segundo parcial - ETSIA - 1 de junio 2007 Solución del examen de Redes - Segundo parcial - ETSIA - de junio 2007 Apellidos, Nombre: Grupo de matrícula:. (0,75 puntos) La captura mostrada en la figura siguiente se ha realizado desde un equipo del

Más detalles

Estructura del protocolo OSI

Estructura del protocolo OSI Semana 14 14 Empecemos! En esta última semana del 9no semestre te queremos felicitar por haber llegado hasta aquí con éxito, enfrentando y resolviendo retos relacionados a los tipos de redes. Esperamos

Más detalles

Redes conmutadas y de área local

Redes conmutadas y de área local Redes conmutadas y de área local Jorge Juan Chico , Julián Viejo Cortés 2011-14 Departamento de Tecnología Electrónica Universidad de Sevilla Usted es libre de copiar,

Más detalles

Capítulo 5 Fundamentos de Ethernet

Capítulo 5 Fundamentos de Ethernet Ethernet, en sus varias formas, es la tecnología de red de área local (LAN) más ampliamente utilizada. Los objetivos de su diseño incluye la simplicidad, un bajo coste, la compatibilidad, el poco retardo

Más detalles

TEMA: PROTOCOLOS TCP/IP

TEMA: PROTOCOLOS TCP/IP TEMA: PROTOCOLOS TCP/IP HISTORIA: El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de

Más detalles

Capítulo II: Unión de Voz y Datos.

Capítulo II: Unión de Voz y Datos. : Unión de Voz y Datos. El desarrollo de las telecomunicaciones y de Internet ha hecho que tecnologías enfocadas a la unión de voz y datos, comiencen a ser una realidad tanto en el mundo de los negocios,

Más detalles

Capa de TRANSPORTE. Ing. José Martín Calixto Cely Original: Galo Valencia P.

Capa de TRANSPORTE. Ing. José Martín Calixto Cely Original: Galo Valencia P. Capa de TRANSPORTE Ing. José Martín Calixto Cely Original: Galo Valencia P. Capa de Transporte La Capa 1 crea y transporta las corrientes de bits; La Capa 2 encapsula los paquetes de datos en tramas, y

Más detalles

CAPITULO 4: CONTROL DE CONGESTION

CAPITULO 4: CONTROL DE CONGESTION CAPITULO 4: CONTROL DE CONGESTION Introducción El aspecto central del control de congestión y de la calidad de servicio es el tráfico de datos. En el control de congestión se intenta evitar la congestión

Más detalles

:: Redes :: Introducción a las Redes de Computadores

:: Redes :: Introducción a las Redes de Computadores Versión 28/02/11 :: Redes :: aplicación transporte red enlace física Introducción a las Redes de Computadores David Villa :: http://www.esi.uclm.es/www/dvilla/ 1 Contenidos Concepto

Más detalles

Introducción. 100 Mbps

Introducción. 100 Mbps Transp. 1 Introducción Se llama congestión al exceso de tráfico en alguna parte de una red, que da lugar al exceso de demanda de algún recurso (ancho de banda, memoria, capacidad de procesamiento...) Síntomas:

Más detalles

Ampliación de Data Centers con Cisco Fabric Path

Ampliación de Data Centers con Cisco Fabric Path Informe técnico Ampliación de Data Centers con Cisco Fabric Path Qué aprenderá Las arquitecturas de redes tradicionales están diseñadas con el fin de ofrecer alta disponibilidad para las aplicaciones estáticas,

Más detalles

UNIVERSIDAD NACIONAL DEL COMAHUE

UNIVERSIDAD NACIONAL DEL COMAHUE UNIVERSIDAD NACIONAL DEL COMAHUE Redes de computadoras Internet Juan Carlos Brocca Redes - Internet Descripción Redes - Internet Descripción Física Redes - Internet Descripción Física Sistemas terminales

Más detalles

Proyecto Redes de Computadores I. Protocolo de Voz sobre IP

Proyecto Redes de Computadores I. Protocolo de Voz sobre IP UTFSM Departamento de Electrónica Proyecto Redes de Computadores I Protocolo de Voz sobre IP Fecha 06 de Septiembre 2013 Integrantes Nicolás Oneto Velásquez Nicolás Ramírez Didier Max Sottovia Rodríguez

Más detalles

Jhon Jairo Padilla Aguilar, PhD.

Jhon Jairo Padilla Aguilar, PhD. Redes de Datos-Redes WAN Jhon Jairo Padilla Aguilar, PhD. UPB Bucaramanga Red WAN WAN: Wide Area Network Pueden cubrir un país entero Requieren de Nodos que recogen/distribuyen la información de los usuarios

Más detalles

IP sobre WDM. Introducción. Evolución de la red óptica. IP sobre SDH/SONET sobre WDM. IP sobre Gigabit Ethernet sobre WDM. IP sobre WDM robusto

IP sobre WDM. Introducción. Evolución de la red óptica. IP sobre SDH/SONET sobre WDM. IP sobre Gigabit Ethernet sobre WDM. IP sobre WDM robusto IP sobre WDM Introducción Evolución de la red óptica IP sobre ATM sobre SDH/SONET sobre WDM IP sobre SDH/SONET sobre WDM IP sobre Gigabit Ethernet sobre WDM IP sobre WDM robusto Introducción El aumento

Más detalles

Tendencias en sistemas de comunicación de altas prestaciones:

Tendencias en sistemas de comunicación de altas prestaciones: Conectan nodos en diferentes niveles del sistema (chip, tarjeta, chásis, armario,...). Desarrollado por diseñadores de arquitecturas de altas prestaciones. Comunicar computadores, clasificación redes computación:

Más detalles

Repaso de conceptos Tema 1.- Introducción

Repaso de conceptos Tema 1.- Introducción Clases 2 y 3 Repaso de conceptos Tema 1.- Introducción Dr. Daniel Morató Redes de Ordenadores Ingeniero Técnico de Telecomunicación Especialidad en Sonido e Imagen, 3º curso Material parcialmente adaptado

Más detalles

2.2 Conmutación de circuitos ópticos (OCS)

2.2 Conmutación de circuitos ópticos (OCS) Evaluación de Arquitecturas de Red Híbridas OBS/OCS 23 2.2 Conmutación de circuitos ópticos (OCS) 2.2.1 Redes dinámicas de conmutación de circuitos ópticos Como se ha visto en el apartado 2.1.2 la conmutación

Más detalles

Tema 4: Redes de conmutación

Tema 4: Redes de conmutación Tema 4: Redes de conmutación Introducción... 1 Redes de conmutación de circuitos... 2 Conmutación por división en el espacio... 3 Conmutación por división en el tiempo... 4 Conmutación de paquetes... 5

Más detalles

Conmutación. Conmutación telefónica. Justificación y definición.

Conmutación. Conmutación telefónica. Justificación y definición. telefónica Justificación y definición de circuitos de mensajes de paquetes Comparación de las técnicas de conmutación Justificación y definición. Si se atiende a las arquitecturas y técnicas utilizadas

Más detalles

Facultad de Ingeniería Redes y Comunicaciones Tercer Parcial Parte Teórica 25%

Facultad de Ingeniería Redes y Comunicaciones Tercer Parcial Parte Teórica 25% NOMBRE: En cada una de las siguientes preguntas de selección múltiple usted podrá seleccionar una o varias respuestas. En el caso de las preguntas que tienen múltiples opciones como respuestas, SOLO será

Más detalles

3 Redes de Acceso Alámbricas

3 Redes de Acceso Alámbricas 3 Redes de Acceso Alámbricas 3.1 INTRODUCCIÓN En nuestros días se está viviendo la evolución de las redes de comunicaciones hacia redes de Alta Velocidad, en las que la filosofía en la que éstas se basaban

Más detalles

TELEFONÍA A IP. Lic. RODRÍGUEZ GÓMEZ, GISELA. Dpto. INFORMÁTICA. UNIVERSIDAD NACIONAL DEL NORDESTE CORRIENTES

TELEFONÍA A IP. Lic. RODRÍGUEZ GÓMEZ, GISELA. Dpto. INFORMÁTICA. UNIVERSIDAD NACIONAL DEL NORDESTE CORRIENTES TELEFONÍA A IP Lic. RODRÍGUEZ GÓMEZ, GISELA Dpto. INFORMÁTICA. UNIVERSIDAD NACIONAL DEL NORDESTE CORRIENTES Introducción La Telefonía IP es un nuevo sistema de comunicación que permite convertir la voz

Más detalles

Capítulo 1: Introducción - I

Capítulo 1: Introducción - I Capítulo 1: Introducción - I ELO322: Redes de Computadores Tomás Arredondo Vidal Este material está basado en: material de apoyo al texto Computer Networking: A Top Down Approach Featuring the Internet

Más detalles

TELEINFORMÁTICA Y REDES DE COMPUTADORAS

TELEINFORMÁTICA Y REDES DE COMPUTADORAS TELEINFORMÁTICA Y REDES DE COMPUTADORAS Por : Avid Roman Gonzalez INTRODUCCIÓN LAS REDES DE COMUNICACIÓN DE DATOS Concepto Sistemas de comunicación de datos son todos aquellos sistemas de información cuyos

Más detalles

Examen de Arquitectura de Redes Sistemas y Servicios (Teoría) 3 o Ingeniería de Telecomunicación Mayo 2011

Examen de Arquitectura de Redes Sistemas y Servicios (Teoría) 3 o Ingeniería de Telecomunicación Mayo 2011 Nombre y apellidos: DNI: 1 Examen de Arquitectura de Redes Sistemas y Servicios (Teoría) 3 o Ingeniería de Telecomunicación Mayo 2011 Test previo: Duración: 0.5 horas. Se permiten libros y apuntes. Pregunta

Más detalles

dit Apellidos: UPM Nombre:

dit Apellidos: UPM Nombre: dit Apellidos: UPM Nombre: DEPARTAMENTO DE INGENIERÍA DE SISTEMAS TELEMÁTICOS ASIGNATURA: REDES Y SERVICIOS DE TELECOMUNICACIONES Renuncia, o ha renunciado ya, a la evaluación continua: Sí - No. Firma:

Más detalles

Historia y Conceptos Generales. Definción, Clasificación de Redes y Topologías

Historia y Conceptos Generales. Definción, Clasificación de Redes y Topologías Historia y Conceptos Generales Definción, Clasificación de Redes y Topologías Antecedentes Evolución de la tecnología (aparición de los sistemas de cómputo modernos: ENIAC, EDVAC, UNIVAC, etc.) Los sistemas

Más detalles

Redes de Computadoras Ethernet conmutada

Redes de Computadoras Ethernet conmutada Redes de Computadoras Ethernet conmutada Ing. Eduardo Interiano Ing. Faustino Montes de Oca Contenido Diversos problemas de las comunicaciones LAN Segmentación de LAN Equipos de comunicaciones LAN Conmutación

Más detalles

Gestión de cola. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 3º

Gestión de cola. Area de Ingeniería Telemática http://www.tlm.unavarra.es. Grado en Ingeniería en Tecnologías de Telecomunicación, 3º Gestión de cola Area de Ingeniería Telemática http://www.tlm.unavarra.es Grado en Ingeniería en Tecnologías de Telecomunicación, 3º Control de congestión en TCP Congestion Avoidance Vamos a ver lo que

Más detalles

1908 Arquitectura de Redes

1908 Arquitectura de Redes 1908 Arquitectura de Redes Tema 5. Control de Tráfico y Control de Congesión Pedro M. Ruiz Francisco J. Ros 3º Grado en Ingeniería Informática 2011/2012 Organización del tema

Más detalles

Líneas de Comunicación Remota

Líneas de Comunicación Remota Líneas de Comunicación Remota Punto a Punto/Internet Por: Prof. Luis M. Cardona Hernández Universidad Interamericana de Puerto Rico Recinto de Bayamón Introducción En esta presentación veremos los principales

Más detalles

FUNDAMENTOS DE REDES Arquitectura de Redes Modelo de referencia OSI y TCP/IP

FUNDAMENTOS DE REDES Arquitectura de Redes Modelo de referencia OSI y TCP/IP FUNDAMENTOS DE REDES Arquitectura de Redes Modelo de referencia OSI y TCP/IP Dolly Gómez Santacruz dollygos@univalle.edu.co Arquitectura de Redes Introducción Las comunicaciones en redes son complejas,

Más detalles