laboratorio atm con opnet

Post on 01-Dec-2015

260 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

PRACTICA – ATM UTILIZANDO OPNET UNA TECNOLOGÍA ORIENTADA A CONEXIÓN MEDIANTE CONMUTACIÓN DE

CELDAS

OSCAR MONSALVO ANDRES GUTIERREZ

FRANCISCO GIACOMETTO MIRIAM GONZALEZ

SAUL CASTRO

ENTREGADO AL ING. JESUS GARCIA

UNIVERSIDAD POPULAR DEL CESAR FACULTAD DE INGENIERIAS Y TECNOLOGICAS

PROGRAMA DE INGENIERIA ELECTRONICA VALLEDUPAR

2008

INTRODUCCION A ATM

ATM es una tecnología de conmutación de paquetes orientada a conexión. Los paquetes que son conmutados en una red ATM son de una longitud fija (53 bytes) y son llamados celdas. El tamaño de la celda tiene un efecto particular altamente efectivo para llevar tráfico sensible al retardo, como la voz. La capa AAL y específicamente su cabecera, contiene la información necesaria para que el destino pueda reensamblar las celdas individuales en el mensaje original. Debido a que ATM fue diseñado para soportar toda clase de servicios, incluyendo voz, video y datos, es necesario definir diferentes niveles de AAL. AAL1 y AAL2 fueron diseñadas para soportar aplicaciones, como la voz, que requieren garantías en la tasa de bits. AAL3/4 y AAL5 proveen el soporte para paquetes de datos que circulan sobre una red ATM. ATM provee capacidades de QoS a través de cinco clases de servicio: CBR, VBR-rt, VBR-nrt, ABR, y UBR. Con CBR (constant bit rate) el origen transmite un flujo de tráfico a una tasa fija. CBR es una buena opción para tráfico de voz que usualmente requiere conmutación de circuitos. UBR (unspecified bit rate) es el encargado del servicio de mejor esfuerzo en ATM. Hay una pequeña diferencia entre UBR y el modelo del mejor esfuerzo (best-effort), debido a que ATM siempre requiere una fase de señalización antes de enviar los datos, UBR permite al origen especificar la máxima tasa que este enviará. Lo switches pueden hacer uso de esta información para decidir si admitir o rechazar el nuevo circuito virtual (VC). En este laboratorio se configurará una red ATM para llevar 3 aplicaciones: Voz, email y FTP, y se estudiará como la escogencia adecuada de la capa de adaptación puede afectar el desempeño de las aplicaciones en la red.

DESARROLLO DE LA PRÁCTICA

� Crear un Nuevo Proyecto

1. Ejecutar OPNET IT Guru Academic Edition � Escoger New del menu File.

2. Seleccionar Project y click en OK � Llamar al proyecto <sus iníciales>_ATM,

y el escenario CBR_UBR � Click en OK.

3. En Startup Wizard: Initial Topology, asegurarse que esta seleccionado Create Empty Scenario � Click en Next � Seleccionar Choose From Maps de la lista Network Scale � Click en Next � Escoger USA de los mapas � Click en Next � de la lista Select Technologies, incluir la familia de modelos atm_advanced, como lo muestra la siguiente figura� Click en Next � Click en OK.

� Crear y Configurar la Red 1. Abrir la paleta de objetos (Object Palette). Hay que asegurarse que este

seleccionada (atm_advanced) de las opciones del menú de la paleta.

2. Adicionar los siguientes objetos, desde la paleta, al espacio de trabajo (Ver figura para la ubicación): Application Config, Profile Config, dos switches atm8_crossconn_adv, y una subnet.

3. Cerrar el dialogo de Object Palette y renombrar (boton derecho en el nodo)� Set

Name) los objetos que se adicionaron como los mostrados en la siguiente figura

4. Salvar el proyecto.

5. Click derecho en el nodo Applications � Edit Attributes � Expandir el atributo Application Definitions y colocar rows en 3 � Nombrar las filas: FTP, EMAIL, y VOICE.

• Ir a la fila FTP � Expandir la jerarquia Description � Asignar High Load a FTP.

• Ir a la fila EMAIL � Expandir la jerarquia Description � Asignar High Load a Email.

• Ir a la fila VOICE� Expandir la jerarquia Description � Asignar PCM Quality Speech a voice.

6. Click derecho en el nodo Profiles � Edit Attributes � Expandir el atributo Profile Configuration y colocar rows en 3.

• Nombrar y colocar los atributos de la fila 0 (row 0) como se muestra en la siguiente figura:

• Nombrar y colocar los atributos de la fila 1 (row 1) como se muestra en la siguiente figura:

• Nombrar y colocar los atributos de la fila 2 (row 2) como se muestra en la siguiente figura (Nota: Para fijar Duration a exponential(60), usted necesita asignar “Not Used” a“Special Value”) � Cerrar el dialogo Object Palette.

7. Configurar la Subred NorthEast:

• Doble Click en el nodo NorthEast. En este momento se mostrará un espacio de trabajo vacio, indicándole que la subred no contiene objetos

• Abrir la paleta de objetos y asegurarse que este seleccionado atm_advanced.

• Adicionar los siguientes items al espacio de trabajo de la subred: un

switch atm8_crossconn_adv, un atm_uni_server_adv, cuatro atm_uni_client_adv, y conectarlos entre ellos con enlaces bidireccionales atm_adv links � cerrar la paleta � renombrar los objetos como se muestra en la siguiente figura:

8. Cambiar el atributo data rate para todos los links a DS1 (T1- 1,544Mbps).

9. Para NE_Voice1 y NE_Voice2, configurar los siguientes atributos:

• Colocar ATM Application Parameters en CBR only. • Expandir la jerarquía ATM Parameters � Colocar Queue Configuration en

CBR only.

• Expandir la jerarquia Application: Supported Profiles � Colocar rows en

1� Expandir la jerarquia de row 0 � Colocar Profile Name en VOICE_P.

• Application: Supported Services � Editar este valor� Colocar rows en 1 � Colocar VOICE en Name de la fila adicionada � Click en OK.

• Expandir la jerarquia Application: Transport Protocol � Voice Transport = AAL2.

10. Para NE_Voice1, Seleccionar Edit Attributes � Editar el valor del atributo

Client Address y escribir NE_Voice1.

11. Para NE_Voice2, Seleccionar Edit Attributes � Editar el valor del atributo Client Address y escribir NE_Voice2.

12. Configurar NE_DataServer de la siguiente manera:

• Application: Supported Services � Editar este valor (Edit) � Colocar rows en 2 � Colocar en Name a las filas adicionadas los siguientes nombres: EMAIL y FTP � Click en OK.

• Expandir la jerarquia Application: Transport Protocol Specification � Voice

Transport = AAL2. • Editar el valor del atributo Server Address y escribir NE_DataServer.

13. Para NE_Data1 y NE_Data2, configurar los siguientes atributos:

• Expandir la jerarquia ATM Parameters � Colocar Queue Configuration en UBR.

• Expandir la jerarquia Application: Supported Profiles � Colocar rows en 2

� Colocar en Profile Name, FTP_P (para row 0) y EMAIL_P (para row 1).

14. Para NE_Data1, seleccionar Edit Attributes � Editar el valor del atributo Client Address y escribir NE_Data1.

15. Para NE_Data2, seleccionar Edit Attributes � Editar el valor del atributo Client Address y escribir NE_Data2.

16. Adicionar las subredes faltantes: Ahora que ya se ha completado la configuración

de la subred NorthEast, se debe devolver al espacio de trabajo del proyecto (click en el botón Go to the higher level.) Las subredes de las otras regiones son

similares a la subred NorthEast excepto en los nombres y las direcciones de los clientes.

17. Hacer 3 copias de la subred que se acaba de crear.

18. Renombrar (� Set Name) las subredes y conectar los switches con enlaces bidireccionales atm_adv como se muestra en la figura. (Nota: los enlaces entre las subredes se debe hacer entre “switch” para cada una de las que se conectan en el diagrama).

19. Cambiar data rate para todos los enlaces a DS1.

20. Seleccionar y dar doble-click en cada una de las nuevas subredes (4 subnets) y cambiar names, client address, y server address de los nodos dentro de estas subredes apropiadamente (p.e, remplazar NE con SW para la subred SouthWest).

21. Para todas las estaciones de voz (voice stations) en todas las subredes (total 8 estaciones), Editar el valor del atributo Application: Destination Preferences de la siguiente manera:

• Colocar rows en 1 � Colocar Symbolic Name a Voice Destination � Click en (…) bajo la columna Actual Name � Colocar rows en 6 � para cada fila escoger una estación de voz que no este en la actual subred. La siguiente figura muestra los nombres actuales para una de las estaciones de voz en la subred NorthEast:

PARA LA ESTACION SO

PARA LA ESTACION SE

PARA LA ESTACION NE

PARA LA ESTACION NO

22. Para todas las estaciones de datos (data stations) en todas las subredes (total de 8 estaciones), Editar el valor del atributo Application: Destination Preferences de la siguiente manera:

• Colocar rows en 2 � Colocar Symbolic Name a FTP Server para la primera fila y Email Server para la segunda� para cada nombre simbólico (p.e., FTP Server y Email Server) Click en (…) bajo la columna Actual Name � Colocar rows en 3 � para cada fila escoger un servidor de datos (data server) que no esté en la actual subred. La siguiente figura muestra los nombres actuales para una de las estaciones de datos en la subred NorthEast:

PARA LA ESTACION NO

Y TANTO Ftp_Server COMO Email_Server TIENEN LA SIGUIENTE CONFIG.

PARA LA ESTACION NE

Y TANTO Ftp_Server COMO Email_Server TIENEN LA SIGUIENTE CONFIG.

PARA LA ESTACION SE

Y TANTO Ftp_Server COMO Email_Server TIENEN LA SIGUIENTE CONFIG.

PARA LA ESTACION SO

Y TANTO Ftp_Server COMO Email_Server TIENEN LA SIGUIENTE CONFIG.

23. Para todos los switches en la red (total de 6), configurar Max_Avail_BW de la cola CBR (queue CBR) al 100%, como se muestra a continuación, y Min_Guaran_BW a 20%.

� Escoger las Estadísticas. Para probar el desempeño de las aplicaciones definidas en la red, se recolectarán una de muchas estadísticas disponibles de la siguiente manera:

1. Click con el Botón Derecho en cualquier lugar del espacio de trabajo y seleccionar Choose Individual Statistics del menu.

2. En el dialogo Choose Results, verificar las siguientes estadísticas:

3. Click en OK.

� Configurar la simulación. Es necesario configurar la duración de la simulación:

1. Click en el boton Configure/Run Simulation.

2. Colcar la duración en 10.0 minutes.

3. Click en OK. (la simulación se correrá posteriormente)

� Duplicar el Escenario. En la red que se creó, se usó la clase de servicio CBR para las aplicaciones de voz y la clase de servicio UBR para las aplicaciones FTP y email. Para analizar el efecto de escoger diferentes clases de servicio, se creará otro escenario similar al escenario CBR_UBR que se acabó de crear, pero se usará solo UBR para todas las aplicaciones. Adicionalmente para probar el efecto de la capa de adaptación de ATM, en el nuevo escenario se usará AAL5 para las aplicaciones de voz.

1. Seleccionar Duplicate Scenario del menu Scenarios y darle el nombre de

UBR_UBR � Click en OK

2. Para todas las estaciones de voz en todas la subredes (8 en total), reconfigurarlas de la siguiente manera.

• Colocar ATM Application Parameters en UBR only • ATM Parameters � Colocar Queue Configuration en UBR.

• Application: Transport Protocol � Colocar Voice Transport a AAL5.

� Ejecutar la simulación. Para ejecutar la simulación de los tres escenarios simultáneamente:

• Ir al menu Scenarios � seleccionar Manage Scenarios.

• Cambiar los valores de la columna Results a <collect> (o <recollect>) para los dos escenarios.

RESUMEN DE LA SIMULACION

� Ver los resultados. Para ver y analizar los resultados:

1. Seleccionar Compare Results del menu Results.

2. Cambiar la opción As Is del menú inferior de Compare Results a time_average.

3. Seleccionar de las estadísticas de voz Packet Delay Variation y click en Show. La grafica resultante se debe parecer a la siguiente. (NOTA: los resultados pueden variar si los nodos se ubicaron en lugares diferentes).

PREGUNTAS

1. Analizar los resultados obtenidos en la gráfica Packet Delay Variation time de la aplicación de voz. Obtener las gráficas y comparar Voice packet end-to-end delay, download response time para Email y FTP download response time para ambos escenarios. Comentar los resultados.

Packet Delay Variation time

A partir de la grafica se puede observar que en el escenario CBR_UBR (donde los servicios de voz han sido asignados con un QoS de AAl2 con CBR) se presenta un retraso constante y muy bajo en toda la duración de la simulación de la red. Caso contrario que ocurre con el escenario UBR_UBR en el cual los servicios de voz fueron negociados a nivel AAL5 con UBR notándose un evidente retraso excesivo al inicio de la simulación.

Voice packet end-to-end delay

Es fácil apreciar que la latencia de los paquetes de voz en la red tiende a bajar el tiempo ya sea que el servicio de voz este negociado con AAL5 o AAl2, lo que se debe tener en cuenta es que el servicio de voz negociado con AAL2 y Bit Rate Constante permite a los paquetes permanecer menos tiempo esperando en la red.

download response time para Email

En la grafica se puede apreciar que al estar los servicios de voz negociados en AAL5 con UBR en el escenario UBR_UBR, afectan el buen funcionamiento de la red sobrecargándola y haciendo el tiempo de descarga de paquetes de EMAIL más alto, que su homónimo en el escenario CBR_UBR.

FTP download response time

En la grafica se puede apreciar que al estar los servicios de voz negociados en AAL5 con UBR en el escenario UBR_UBR, afectan el buen funcionamiento de la red sobrecargándola y haciendo el tiempo de respuesta en la descarga de paquetes FTP sea más alta, que su homónimo en el escenario CBR_UBR.

2. Crear otro escenario duplicando el escenario CBR_UBR. Nombrarlo como

Q2_CBR_ABR. En el nuevo escenario debe usar la clase ABR para los servicios de datos (aplicaciones FTP y email) en las estaciones de datos. Comparar el desempeño del escenario CBR_ABR con el escenario CBR_UBR.

• NOTA:

Para asignar la clase ABR a un nodo, asignar ABR Only al atributo ATM Application Parameters y ABR only (Per VC Queue) a Queue Configuration (Uno de los parametros ATM - ATM Parameters). Para todos los switches en la red (6 switches), configurar Max_Avail_BW de la cola ABR a 100% y Min_Guaran_BW a 20%.

Para los switch.

Comparacion cbr_ubr con cbr_abr

Observamos para E-mail que con tasa de bit disponible (ABR), el tiempo de respuesta de descarga es menor que utilizando UBR, Se hace una mejor gestión de la capacidad sobrante que con UBR. Aunque al final tienden a ser iguales las respuestas.

Observamos para FTP que las respuestas son muy parecidas. Eso quiere decir que para FTP no hay mucha diferencia en negociar con UBR o ABR.

Lo mismo ocurre para el tráfico de voz.

3. Editar la aplicación FTP definida en el nodo Applications cambiando File Size al doble del tamaño actual (p.e., 100000 bytes si esta 50000 bytes). Editar la aplicación EMAIL definida en el nodo Applications cambiando File Size aumentándolo cinco veces al valor del tamaño actual (p.e., 10000 bytes si esta 2000 bytes). Estudiar como estos cambios afectan al desempeño de la aplicación para los escenarios CBR_UBR y UBR_UBR.

• (Nota: para responder esta pregunta es necesario crear escenarios duplicados de CBR_UBR y UBR_UBR. Nombrarlos Q3_CBR_UBR y Q3_UBR_UBR).

DUPLICACION DE ESCENARIOS

Comparación entre cbr_ubr y q3_cbr_ubr

Email download response time

En la grafica se puede apreciar que al aumentar el tamaño del archivo EMAIL en el escenario q3_cbr_ubr se consigue un mayor retraso en la descarga del archivo EMAIL.

FTP download response time

En la grafica se puede apreciar que al aumentar el tamaño del archivo FTP en el escenario q3_cbr_ubr se consigue un mayor retraso en la descarga de los paquetes FTP.

Voice Packet End-to-End Delay

En la grafica se puede concluir que al aumentar el tamaño del archivo FTP y EMAIL, en una red donde se han negociado servicios de voz en la capa AAL2 con CBR, la latencia de los paquetes de voz en la red tiende a aumentar.

Voice Packet Delay Variation

En la grafica se puede concluir que al aumentar el tamaño del archivo FTP y EMAIL, en una red donde se han negociado servicios de voz en la capa AAL2 con CBR, el retraso con respecto a los paquetes de voz enviados en la red tiende a ser el mismo y no es afectado en lo mas mínimo por el tamaño de los archivos de las aplicaciones de datos.

Comparación entre los escenarios ubr_ubr y q3_ubr_ubr.

Email download response time

En la grafica se puede apreciar que al aumentar el tamaño del archivo EMAIL en el escenario q3_ubr_ubr se consigue un mayor retraso en la descarga del archivo EMAIL.

FTP download response time

En la grafica se puede apreciar que al aumentar el tamaño del archivo FTP en el escenario q3_ubr_ubr se consigue un mayor retraso en la descarga de los paquetes FTP.

Voice Packet End-to-End Delay

En la grafica se puede concluir que al aumentar el tamaño del archivo FTP y EMAIL, en una red donde se han negociado servicios de voz en la capa AAL5 con UBR, la latencia de los paquetes de voz en la red tiende a disminuir.

Voice Packet Delay Variation

En la grafica se puede concluir que al aumentar el tamaño del archivo FTP y EMAIL, en una red donde se han negociado servicios de voz en la capa AAL5 con UBR, el retraso con respecto a los paquetes de voz enviados en la red tiende a aumentar.

4. Duplicar el escenario CBR_UBR llamándolo Q4_CBR_UBR_VIDEO. En email), Video conferencia en video de alta resolución. Configurar los parámetros adecuadamente según los criterios adecuados de clasificación de tráfico en las clases de servicio de ATM (como se vio en la clase y se realizó en la guía), haciendo todos los cambios pertinentes. Analizar comparando con el escenario CBR_UBR como afectaría (si es que lo hace) a las aplicaciones que antes estaban en la red (voz, FTP y email).

• (Nota: Los únicos cambios deben hacerse a la nueva aplicación, las otras no se deben modificar, solo analizar)

Para hacer la duplicación de escenario se debe situar en el escenario a copiar en este caso CBR_UBR, luego dirigirse al menú SCENARIOS ������������� ��������������������������������������

Luego de esto en el escenario Q4_ CBR_UBR se debe configurar la aplicación que se va a implementar (video)

Click derecho en el nodo Applications � Edit Attributes � Expandir el atributo Application Definitions y colocar rows en 4 � Nombrar la ultima fila: VIDEO. Expandir la jerarquia Description � Asignar High Resolution Video a Video Conferencing.

Luego en perfiles en la opción configuración de perfiles se adiciona otra columna con el nombre de VIDEO_P y en esta una columna con el nombre de video y se asignan valores de acuerdo a la grafica mostrada.

A continuación en cada una de las subredes se debe a proceder a colocar un equipo de video conferencia, esto se hace abriendo la paleta de objetos adicionando un atm_uni_client_adv, conectándolo con el SW con enlaces bidireccionales atm_adv.

Luego se debe proceder a configurar sus parámetros del equipo de la siguiente forma, Click derecho en el nodo Applications � Edit Attributes. Los parámetros se llenaran de acuerdo al cuadro mostrado.

El parámetro (aplicación: servicios soportados) se llene como muestra el posterior cuadro.

El parámetro (aplication: destination services) tiene que ser llenado de la siguiente manera.

Y el campo Actual name se rellena de la siguiente forma.

Cuando se ha completado de posicionar todos los clientes de video se termina recolectando la información de los escenarios a simular como muestra la figura, esto se hace en la opción manage scenarios del menú scenarios.

Después de recolectar las graficas, seleccionar Compare Results del menu Results cambiar la opción As Is del menú inferior de Compare Results a time_average. Resultados obtenidos en la gráfica Packet Delay Variation

En esta grafica se hace notar que el retraso con respecto a los paquetes de voz enviados en la red no sufre ningún cambio se que exista o no el servicio de video conferencia en esta, esto ocurre cuando el servicio de video conferencia esta en el protocolo de transferencia AAL2.

Voice packet end-to-end delay

En esta grafica se hace notorio que los paquetes del escenario con voz montada sobre el QoS CBR con AAl2 sin los equipos de video conferencia logran un retraso un poco elevado al principio de la conexión pero con el tiempo este retrazo tiende a bajar, caso contrario pasa con los paquetes cuando estos tienen en la misma red equipos de video conferencia utilizando el QoS CBR con AAl2.

Email download response time

Observando la grafica de puede concluir que el escenario sin equipos de video conferencia logra menor tiempo de descarga de paquetes Email, con respecto al escenario que posee dichos equipos.

FTP download response time

Observando la grafica se puede concluir que el escenario sin equipos de video conferencia logra menor tiempo de descargas de paquetes FTP, con respecto al escenario que posee dichos equipos.

top related