USING OPNET TO IMPLEMENT A TRAFFIC MODEL OF A FTTX NETWORK TO VOICE AND DATA TRANSMISSION

Transcripción

1 USING OPNET TO IMPLEMENT A TRAFFIC MODEL OF A FTTX NETWORK TO VOICE AND DATA TRANSMISSION UTILIZACIÓN DE OPNET PARA LA REALIZACIÓN DE UN MODELO DE TRÁFICO EN UNA RED FTTX DE TRANSMISIÓN DE VOZ Y DATOS 1.- Introduction The proposed goal in the accomplishment of this work is the implementation of the complete model of a FTTX network for voice and data transmission, so that it reproduces the traffic generated in the different elements from the system. For it, based on the previous works [Garcia, 2003] and MODELING REAL TRAFFIC IN CABLE NETWORK USING OPNET, we present a complete model of cable network. The system object of study corresponds to the real network implanted by the company Telecable, S.A., entity that has provided real traffic, which allows the later validation of the results obtained with the model. The model implementation begins with a load model that represents the usage that the network subscribers do of the system, allowing to generate requests sent by the subscribers who are connected in each upstream. The destiny of requests can be any other subscriber of the network, the operator servers or an external server who is outside the network. In order to drive requests to their final destiny, the models of each one of the branches of the complete network have been implemented, considering so much the upstream channels as the downstream from the controller, as well as the commutators ATM that transport the information through the optical fiber ring to 155Mbps and routers to drive the traffic to the corresponding serverss. The connections are made through links to 30Mbps and 155Mbps according to the traffic necessities in each point. In addition, also has been modeled the behavior of the system servers, the own servers of the cable operator and the connected external servers to Internet. These devices, besides to receive requests from the users, respond generating a traffic in opposite sense that it has as destiny the initial origin of the request. Para la realización del modelo se ha utilizado el programa de simulación OPNET y los resultados obtenidos con el simulador han sido exportados a MATLAB lo que permite realizar todo tipo de análisis estadísticos con ellos, con ánimo de realizar tanto la verificación de los resultados como la validación del modelo realizado a partir de los datos reales. OPNET simulation program has been used to implement the network model and the obtained results exported to MATLAB, which allows to make all type of statistical analyses with them, to make the verification of the results and the model validation made from the real data. One of the advantages that present the developed model is its facility of interpretation, since it responds to the physical topology of the network to study. From the initial model, the scalability can be made simply adding more branches to the ring, configuring the users of each channel, which allows to evaluate the behavior of different elements from the system with a growth of the network and to observe the resources usability available. Another advantage is the possibility of using the backgrounf traffic and to simulate the behavior with the inclusion of new services (VoIP, VoD, etc) with certain QoS, as well as to evaluate the operation of the acces protocols (DOCSIS). 1

2 2.- Visión general del sistema El modelo completo de la red de cable realizado se representa en la figura 1, donde puede observarse la estrategia seguida en el modelado. Figura 1.- Modelo completo de la red de cable Se ha seguido un diseño jerárquico donde cada una de las ramas de la red se representa mediante una subred conectada al anillo de fibra óptica. En cada una de estas ramas los nodos UPX representan las peticiones de los usuarios del canal de retorno, el nodo HCX implementa el modelo del controlador de la red HFC y el nodo switch es el conmutador ATM encargado de conectar la rama con el anillo de transporte. Los abonados se encuentran conectados a la red a través de cable-módems y disponen de un canal de retorno por el que emiten su información. Los usuarios se encuentran asignados estáticamente a uno de los 6 canales de retorno manejados por el controlador. Reciben la información por un canal de bajada común a todos los abonados a la rama., y se conectan a la red a través del controlador HCX (Headend Channel Switch) que proporciona la interfaz entre la red de cable interna (rama) y la red exterior. La comunicación entre los cable-módems y el controlador HCX se realiza a través de una red híbrida de fibra y coaxial formada por varios nodos ópticos, que realizan la conversión de señal óptica a eléctrica, utilizando cable coaxial para llevar la información a los abonados y fibra óptica desde el controlador hasta los nodos ópticos. Puede observarse en la figura 1 la disposición de los distintos elementos del sistema, así como su utilidad para el correcto funcionamiento de la red. 2

3 4.- Formato de transmisión de la información Para transmitir la información a través de la red se han fragmentado las distintas peticiones y respuestas de usuarios y servidores en celdas ATM para su encaminamiento por los distintos elementos del sistema. El formato de paquete utilizado, roberto_pkt_atm, permite identificar el origen de la información, el destino, el tipo de tráfico que transporta, el final de la petición mediante el campo MF y también proporciona un identificador de la petición realizada, como se muestra en la figura 2. rama origen (8 bits) rama destino (8 bits) canal origen canal destino (4 bits) tipo tráfico (4 bits) identificador (8 bits) campo de datos (48 bytes) (4 bits) más fragmentos (4 bits) Figura 2.- Formato del paquete utilizado La dirección de origen queda determinada por la rama origen y por el canal de origen de la información, utilizándose el mismo criterio para determinar la dirección destino de las peticiones. El significado de cada uno de los campos que componen el paquete queda definido en la tabla siguiente. rama_origen rama_destino Controlador canal_origen canal_destino 0 Cabecera Servidores 0 principal operador 1 HCX1 1 Servidores remotos 2 HCX2 4 Upstream 4 N HCXN 9 Upstream 9 Localización Tipo_trafico Trafico 0 Interactivo 1 Peer-topeer El campo más fragmentos (MF) es un indicador utilizado en la fragmentación y posterior reensamblado de los paquetes originales. A fragmentar el paquete de datos, todas las celdas tienen 1 en ese campo indicando la presencia de más celdas en la petición, excepto la última que tiene el bit MF puesto a 0. Además, para el correcto reensamblado de los paquetes se ha incluido un campo identificador, que será el mismo en todas las celdas en que se ha dividido la petición, de manera que con este campo y las direcciones origen y destino quedaría identificado de forma única el paquete que se quiere reconstruir. 3

4 5.- Generación de tráfico en los canales de retorno En este apartado se describe el comportamiento de los nodos UPX, encargados de generar tráfico en los canales de retorno de la red. La funcionalidad de estos nodos se representa en el diagrama de la figura 3, implementado en el nivel de modelado de nodos de OPNET. Puede observarse la distinción entre dos tipos de tráfico: Tráfico interactivo: Tráfico que refleja peticiones hechas por los usuarios de forma interactiva, que depende de la presencia de los usuarios conectados a la red Tráfico peer-to-peer (P2P): Tráfico independiente de los abonados conectados, que se debe al funcionamiento de las aplicaciones peer-topeer. El tráfico en los canales de retorno estará formado por la agregación de estos dos tipos de tráfico, tal y como se aprecia en la figura 3. Figura 3.- Modelo de los canales de retorno Para modelar el tamaño y el tiempo entre peticiones para los dos tipos de tráfico es necesaria la realización de un estudio previo de los datos reales proporcionados por el operador de red. Dicho análisis se presenta de forma exhaustiva en [García, 2003], donde puede apreciarse la rigurosidad en el tratamiento estadístico de la información disponible, además de un completo y profundo análisis que ha permitido la realización de este modelo con el simulador OPNET. De este análisis de la información disponible se obtienen tanto los tamaños de los paquetes generados como el tiempo entre peticiones consecutivas. Para la generación de los distintos tipos de tráfico se siguen las distribuciones adecuadas de acuerdo a trabajos de investigación realizados en este campo. 4

5 Así, para el tráfico peer-to-peer se utiliza una distribución de Pareto para el tamaño de los paquetes, ya que este tráfico procede de aplicaciones de transferencia de ficheros ([Crovella and Bestavros, 1997]). El tiempo entre peticiones se modela siguiendo una distribución exponencial. Para el tráfico interactivo, se calcula el tráfico generado por cada abonado y se envían tantas peticiones como abonados estén conectados en ese momento a la red. Para el tamaño de los paquetes se sigue una distribución normal y para el tiempo entre peticiones una distribución exponencial por ser la que mejor representa los eventos de naturaleza humana. La función de los módulos interactivo y P2P en el nodo es la de generar las peticiones de los usuarios de acuerdo con las distribuciones obtenidas en el proceso de análisis. En el caso de la generación de tráfico interactivo se realizarán tantas peticiones como usuarios se encuentren conectados en ese momento al canal de retorno. Este valor se obtiene calculando la transformada de Fourier del porcentaje de abonados conectados al sistema en función del tiempo y es actualizada por el programa cada 5 minutos. Otro aspecto destacable de estos módulos es el procedimiento de obtención de las direcciones de destino de los paquetes. Así, observando el flujo de información en la red objeto de estudio, se han direccionado las peticiones a los siguientes destinos: Tráfico interno: Tráfico dirigido a otros usuarios conectados a canales de retorno en cualquier rama de la red. Se han destinado el 2% de las peticiones Tráfico externo: Tráfico dirigido al exterior de la red de cable. Representa el 98% de las peticiones de los usuarios. Se divide en dos tipos: o Tráfico dirigido a los servidores propios del operador: 0.5% del tráfico externo o Tráfico dirigido a Internet: 99.5% del tráfico externo Para la selección de los diferentes destinos se han seguido distribuciones uniformes. El módulo agregado realiza la fragmentación de los paquetes generados en celdas ATM con el formato indicado en el apartado 4. Todas las celdas generadas llevan un identificador de la petición, así como un bit MF que indica la última celda de la petición cuando está puesto a 0. En la figura siguiente se indica el proceso de este módulo encargado de realizar la fragmentación de los paquetes en celdas ATM. 5

6 int numero_celda; pkptr=op_pk_get(op_intrpt_strm()); tamano_paquete=(d1ouble)op_pk_bulk_size_get(pkptr); celdas=(int)ceil(tamano_paquete/384.0); /* Numero de celdas ATM del paquete */ op_pk_nfd_set(pkptr,"identificador",identificador); identificador++; if (identificador >= 255) { identificador=0; op_pk_bulk_size_set(pkptr,384); tamano_paquete=op_pk_total_size_get(pkptr); if (celdas > 1) { op_pk_nfd_set(pkptr,"mf",1); /* El paquete tiene mas fragmentos */ for (numero_celda=1;numero_celda < celdas;numero_celda++) { celda_atm=op_pk_copy(pkptr); op_pk_send(celda_atm,ssc_strm_inferior); /* Pongo a 0 el bit de MF... */ op_pk_nfd_set(pkptr,"mf",0); /* y envio la ultima celda al stream inferior */ op_pk_send(pkptr,ssc_strm_inferior); op_stat_write(trafico_total_stat,celdas*tamano_paquete); op_stat_write(trafico_total_stat,0.0); Figura 4.- Proceso de fragmentación en celdas ATM Los atributos que permiten configurar las características del canal de retorno se muestran en la figura 5. A la hora de conectar este nodo en el modelo se debe indicar el canal de retorno asignado (valores desde 4 hasta 9), la rama (controlador HCX) en que se encuentra conectado y el número de abonados asignados al canal de retorno. 6

7 Figura 5.- Atributos de configuración del nodo UP4 6.-Modelado del comportamiento del controlador HCX El concentrador HCX es el dispositivo que sirve de interfaz entre la red de cable y la red exterior. Las principales características son: Soporta hasta 8 canales en sentido ascendente (implementados 6 en la red real del operador) Proporciona la información a los usuarios a través de un canal de bajada (dowstream) Realiza funciones de reenvío de datos, filtrado y permite definir clases de servicio Cumple el estándar DOCSIS Su capacidad de reenvío es de paquetes por segundo Su configuración interna se indica en la figura 6, donde se pueden apreciar algunas de las características mencionadas. 7

8 Figura 6.- Módulos del nodo cabecera Las peticiones de los usuarios llegan al controlador a través de los 6 canales de retorno disponibles. Estos paquetes de información pueden ser enviados a la red exterior o bien puede tratarse de tráfico interno con destino a algún usuario de la red. En este caso la información se entrega por el canal de bajada al usuario correspondiente. En cuanto a la información procedente de la red exterior recibirá el mismo tratamiento que la procedente de los canales de retorno. Una vez procesada, con una capacidad de procesamiento del controlador de pps modelado mediante la cola correspondiente, será enviada a la dirección de destino. Puede observarse en el modelo la existencia de 2 colas que representan el procesamiento de cada paquete. En el caso de la cola de entrada se modela la capacidad de reenvío del controlador (50000pps) y en la cola del canal de bajada la capacidad de transmisión de este canal (23.9Mbps). La función de cada uno de los módulos del controlador será la siguiente: Módulos receptores y transmisores: Aceptan los paquetes de entrada y envían los paquetes al destino correspondiente. Están configurados para trabajar a una velocidad binaria de 30Mbps y soportar el formato de paquete roberto_modelo_red. Módulo tráfico_agregado: Calcula el tamaño del tráfico agregado de los canales de retorno y envía el tráfico a la cola de entrada del controlador Módulo procesador: Envía el paquete que llega según la dirección de la rama destino especificada en el campo correspondiente. Si el campo rama_destino coincide con la dirección del HCX se envía el tráfico por el canal de bajada y si no coincide se envía a la red exterior. Módulo canal_bajada: Envía el paquete por el canal correspondiente. Si el destino es incorrecto se destruye el paquete. También calcula el tráfico por el canal de bajada así como el porcentaje de utilización del canal de bajada. 8

9 7.- Modelo del conmutador ATM El conmutador ATM se encarga de conectar las ramas correspondientes a las redes donde se encuentran los usuarios con el backbone principal de fibra óptica, como se indica en la figura 1. Con una capacidad de procesamiento de 7 millones de paquetes por segundo, modelado mediante una red tipo acp_fifo, puede recibir celdas ATM por cualquiera de sus canales (2 canales de 155Mbps con otros conmutadores ATM vecinos y un canal 30 Mbps con el controlador HCX de la rama en que se encuentra conectado) y dirigir la petición a la salida correspondiente según su destino. Figura 7.- Estructura del nodo conmutador ATM Como atributo de configuración para el modelo de red se debe incluir el controlador HCX al que se encuentra conectado. 8.- Modelo del nodo switch principal El modelo del switch principal es análogo al de los conmutadores ATM con la única diferencia de que el canal destinado a la conexión con la rama correspondiente tiene una capacidad de 155 Mbps para poder atender todas las peticiones dirigidas a los servidores a través del router 1. 9

10 Figura 8.- Módulos que componen el nodo switch principal 9.- Nodo encaminador1 El encaminador 1 recibe las peticiones que le llegan del switch principal y las dirige bien a los servidores del operador de la red, bien a la red exterior (internet) a través del encaminador 2. También puede recibir tráfico proveniente de los servidores del operador o de internet y redirigirlo a su destino. En la figura 9 se ilustra este procedimiento de actuación. Todos los enlaces con sus dispositivos periféricos se realizan a 155Mbps. Figura 9.- Modelo del encaminador Nodo encaminador 2 En la figura 10 se muestran los módulos que componen este nodo. Puede observarse que se encarga de encaminar los paquetes que le llegan por sus líneas de entrada a las lineas de salida correspondientes. También tiene por misión balancear el tráfico con destino a internet entre los dos proveedores de acceso ISP1 e ISP2 que tiene contratados el operador de red. 10

11 Figura 10.- Modelo del encaminador Nodo servidores del operador de cable Cuando las peticiones llegan a los servidores del operador de cable lo hacen con formato de celdas ATM, con la estructura indicada en el apartado 4. Como se ilustra en la figura 11, este nodo realiza el reensamblado de las celdas ATM en paquetes con el tamaño original de la petición, procesa la información según el tipo de tráfico que se trate y, posteriormente, vuelve a fragmentar las respuestas en celdas ATM para su transmisión a través de la red de transporte hasta su destino. Los enlaces son a 155Mbps. Figura 11.- Módulos del nodo de los servidores del operador Los algoritmos encargados del reensamblado y la fragmentación en celdas ATM utilizan el bit MF y el campo identificador de la cabecera de los paquetes. En los cuadros de texto de las figuras 12 y 13 se muestran los algoritmos utilizados en estas etapas. 11

12 ESTADO INICIO /* Inicializo el array a 0 */ for (id=0;id<256;id++) { for (rama=0;rama<20;rama++) { for (canal=0;canal<6;canal++) { pksize[id][rama][canal]=0; ESTADO REENSAMBLADO pkptr=op_pk_get(op_intrpt_strm()); op_pk_nfd_get(pkptr,"rama_origen",&rama_origen); op_pk_nfd_get(pkptr,"canal_origen",&canal_origen); op_pk_nfd_get(pkptr,"mf",&mf); op_pk_nfd_get(pkptr,"identificador",&identificador); canal_origen=canal_origen-4; /* El canal de origen comienza en UP4 */ /* Se incrementa el tamaño del paquete recibido en 48 bytes */ pksize[identificador][rama_origen][canal_origen]+=384; if (MF==0) {1 op_pk_bulk_size_set(pkptr,pksize[identificador][rama_origen][canal_origen]); op_pk_send(pkptr,strm_inferior); pksize[identificador][rama_origen][canal_origen]=0; else { op_pk_destroy(pkptr); Figura 12.- Descripción del módulo reensamblado 12

13 ESTADO TRÁFICO int numero_celda; pkptr=op_pk_get(op_intrpt_strm()); tamano_paquete=(double)op_pk_bulk_size_get(pkptr); celdas=(int)ceil(tamano_paquete/384.0); /* Numero de celdas ATM del paquete */ op_pk_bulk_size_set(pkptr,384); if (celdas > 1) { op_pk_nfd_set(pkptr,"mf",1); /* El paquete tiene mas fragmentos */ for (numero_celda=1;numero_celda < celdas;numero_celda++) { celda_atm=op_pk_copy(pkptr); op_pk_send(celda_atm,ssc_strm_inferior); /* Pongo a 0 el bit de MF... */ op_pk_nfd_set(pkptr,"mf",0); /* y envio la ultima celda al stream inferior */ op pk send(pkptr,ssc STRM INFERIOR); Figura 13.- Módulo fragmentación ATM Debido a la diferente naturaleza del tráfico (interactivo o peer-to-peer) el tratamiento que se hace a las peticiones varía. El tiempo de retardo a las peticiones se determina a partir de la experiencia del operador de red, mientras que el tamaño de los paquetes de respuesta a las peticiones de los usuarios es obtenido a partir del análisis de los datos reales. La función de los distintos módulos del nodo será la siguiente: Módulo procesador_entrada : Configura las direcciones de origen y destino de los paquetes a devolver a los usuarios y envía el paquete de llegada para su procesamiento según el tipo de tráfico que se trate. 13

14 Módulo proc_interactivo : Obtiene el tiempo de retardo y el tamaño de los paquetes para el tráfico interactivo, de acuerdo a las siguientes distribuciones de probabilidad: o Tiempo de retardo: exponencial(100ms) o Tamaño: normal media= *abonados_hcx desviación = 0.27 Módulo proc_p2p : Obtiene el tiempo de retardo y el tamaño de los paquetes para el tráfico peer-to-peer, de acuerdo a las siguientes distribuciones de probabilidad: o Tiempo de retardo: exponencial(200ms) o Tamaño: normal media= *ln(abonados_hcx) desviación = 0.26 Módulo procesador_salida : Envía todo el tráfico al controlador HCX de la red. También calcula y registra el tráfico total enviado por la red exterior al controlador Nodo Internet En este nodo se modela el tratamiento que se hace a las peticiones enviadas a la red exterior. El comportamiento es similar al de los servidores propios del operador, salvo que también se incluye el acceso a internet a través de los proveedores ISP1 e ISP Resultados obtenidos Figura 14.- Nodo internet Para la obtención de resultados de simulación se ha tenido en cuenta la distribución temporal de los datos proporcionados por el operador de la red. Así, los datos ofrecidos se componen de 600 muestras en intervalos de 5 minutos, resultando un total de 50 horas de simulación. Al ejecutar la simulación, con la configuración indicada de 50 horas, el tiempo de ejecución de la simulación se situaba en aproximadamente 600 horas, lo que imposibilitó la realización del experimento. No obstante, para confirmar la validez del modelo desarrollado, se realizó una simulación del comportamiento de la red durante 2 horas, con los resultados que se indican en los perfiles de tráfico de las figuras 15 y sucesivas. 14

15 Figura 15.- Tráfico en los canales de bajada de algunos controladores Figura 16.- Tráfico en distintos puntos de la red Figura 17.- Tráfico en los routers y proveedores de acceso a internet 15

16 Como estadísticas a recoger del modelo simulado se dispone de todo el tráfico presente en los distintos enlaces de la red. Por simplicidad a la hora de mostrar los resultados solamente se presentan las estadísticas de las figuras 15, 16 y 17. En la figura 15 se muestra el tráfico en los canales de bajada de 4 controladores de la ciudad de Gijón (GI01CC01, GI01CC02, GI02CC01 y GI03CCO1) tanto en volumen de tráfico (bits/seg) como en porcentaje de utilización del canal de bajada. Durante el periodo de simulación mostrado, este tráfico es comparable al mostrado en las figuras 11 y 12 del documento Implementación mediante OPNET de un modelo de red de cable.. El volumen de tráfico generado durante el tiempo de simulación se ajusta al tráfico real en la red. En la figura 16.b se observa el tráfico entre el switch 1 y switch principal y entre los conmutadores ATM de las ramas 1 y 2, determinado de esta manera el sentido del flujo de tráfico a través del anillo. En la figura 16.a puede verse como la práctica totalidad de tráfico que llega al encaminador 1 se enruta hacia Internet y sólo un pequeño porcentaje de las peticiones va dirigido a los servidores del operador, como era de esperar. Finalmente, en la figura 17 pueden verse más flujos de tráfico, que ilustran como el tráfico generado por los usuarios de la red de cable se encamina adecuadamente a los destinos designados a través del anillo de fibra óptica. En la figura 17.b se indica la distribución del tráfico de acceso a Internet entre los dos proveedores de servicio contratados (ISP1 e ISP2) Conclusiones El modelo completo de la red FTTX que se presenta permite la generación de perfiles de tráfico estadísticamente comparables con los datos reales proporcionados por el operador de red. Se posibilita la configuración de los diferentes canales de retorno, que incluye el controlador HCX al que se encuentran conectados los abonados, el canal de retorno asignado, así como el número de abonados al canal de retorno. También se tienen en cuenta los dos tipos de tráfico existentes en la red (interactivo y peer-to-peer), proporcionando un trato diferenciado para cada uno de ellos, tanto en las distribuciones empleadas para su generación como en el tratamiento que se da a las peticiones en los servidores del sistema. Tanto el tráfico presente en la red como las rutas que sigue a lo largo del sistema son las esperadas, confirmando así la validez de los modelos utilizados. Finalmente, destacar que la disposición de los elementos del modelo responde a la topología física de la red objeto de estudio, con la facilidad de interpretación del sistema que ello conlleva Mejoras a realizar Una vez comprobado y validado el modelo de generación de tráfico en la red, se pretende incorporar toda la algoritmia desarrollada a los modelos disponibles en las librerías de OPNET con el objetivo de realizar un modelo de carga que implemente toda la arquitectura de protocolos utilizada en la red objeto de estudio. Así, el tráfico generado por los usuarios de la red se considerará en la capa de aplicación, siendo necesaria la implementación de las capas de transporte (TCP), IP y como protocolos de 16

17 las capas inferiores bien ATM o bien Ethernet dependiendo de la funcionalidad del nodo a modelar. Este método de actuación presenta la ventaja de utilizar los modelos proporcionados por OPNET, lo que permitiría un análisis más completo del sistema al tener en cuenta aspectos tales como la implementación de toda la arquitectura de red con sus protocolos correspondientes, el empleo de dispositivos de encaminamiento, switches, routers, que pueden ejecutar distintos algoritmos de enrutado de la información, así como tener en cuenta diferentes velocidades de procesamiento en los dispositivos intermedios, utilizar técnicas de transmisión normalizadas (DS-1,OC-3,OC- 12, OC-48), además de las posibilidades que ofrece OPNET de análisis de cada uno de los protocolos disponibles. También se pretende mejorar el modelo en lo referente al tiempo empleado en la simulación del sistema. Con el modelo actual resulta prácticamente imposible realizar la simulación completa de las 50 horas requeridas. Esto es debido a que la técnica de simulación empleada (simulación explícita) tiene en cuenta cada uno de los paquetes en circulación por la red, provocando una interrupción por cada paquete para modelar su efecto y realizar el tratamiento correspondiente. Este método de simulación por eventos discretos aumenta considerablemente los tiempos de ejecución a medida que crece el número de paquetes en circulación por el sistema. En el caso de la red a analizar, el elevado número de usuarios (más de 17000) provoca tal cantidad de peticiones y paquetes convertidos a celdas ATM circulando por la red que ralentiza enormemente la ejecución del programa. Para tratar de solucionar este problema se plantea una solución basada en una simulación híbrida, donde la mayor parte del tráfico que circule por la red sea modelado analíticamente y solamente el tráfico de interés sea tratado de forma explícita. Con esto se conseguiría reducir considerablemente el tiempo de ejecución de las simulaciones Referencias [802.14, 1998] , W.I. IEEE Project /a draft 3 revision 3: Cable TV access method and physical layer specification. I.Reede, M. Brandt and J. Karaoguz, Eds., Unapproved IEEE Project Draft Specification [Bhagavathula, 2002] Bhagavathula, R., Xianghui Ma, Thanthry, N. and Pendse, R. Voice Over Cable Network. OPNETWORK 2002 [Davids et al, 1998] Davids, N, Ransbotton, S, Hamilton, D. Teaching Computer Networks Through Modeling. ACM SIGAda Ada Letters, Volume XVIII, Issue 5 Sept/Oct 1998, pp [Erramilli et al, 1995] Erramilli, A., Pruthi, P., Willinger, W. Recent Developments in Fractal Traffic Modeling. ITC St. Petersburg Teletraffic Seminar, June 1995 [Floyd and Paxson, 2001] Floyd, S., Paxson, V. Difficulties in Simulating the Internet. IEEE/ACM Transactions on Networking, 2001 [García, 2003] García, M. Modelado de prestaciones de redes de área metropolitana de transmisión de datos, basadas en tecnología híbrida fibra-coaxial. PhD thesis, Universidad de Oviedo 17

18 [García, 2003a] García, M., García, V.G., G.Pañeda, X.X., Bonis, R. Análisis y Modelado de la Red de Datos de un Operador de Cable, 2003 [Hamilton et al, 1999] Hamilton, J.A., Murtagh, J.M., Deal, J.C., Simulation-Based Requirements Engineering for Army Enterprise XXI. Advanced Simulation Technologies Conference Proceedings, San Diego, Calif., April, 1999, pp [Hamilton et al, 1999b] Hamilton, J.A., Ransbottom, J.S., Davis, N.D., An Integrated Approach to Network Simulation, Advanced Simulation Technologies Conference Proceedings, San Diego, Calif., April, 1999, pp [Hamilton et al, 2000] Hamilton, J.A., Deal, J.C., Grobmeier, J.R., Network Modeling and Simulation with Mixed Traffic Data Sources. Conference on Communication Networks and Distributed Systems Modeling and Simulation, San Diego, Ca., Jan., 2000, pp [Kleijnen, 1999] Kleijnen, J.P.C. Validation of models: Statistical techniques and data availability. Proc. of 1999 Winter Simulation Conf., [Paxon and Floyd, 1995] Paxson, V. And Floyd, S. Wide Area Traffic: The Failure of Poisson Modeling. IEEE/ACM Transactions on Networking, 3(June): [Sargent, 2000] Sargent, R.G. Verification, validation and accreditation of simulation models. Proceedings of the 2000 Winter Simulation Conference 18