Capitulo 3

CAPITULO 3 ESTUDIO DE TRFICO
CAPITULO 3
Estudio de Trafico
84
PAUL QUITO
CAPITULO 3
Estudio de Trafico
3.1. ANLISIS DE TRFICO
3.1.1. Introduccin
Dentro de una llamada IP estn presentes el protocolo RTP, UDP, IP y

protocolo Ethernet, los cuales son respectivamente: el protocolo del tipo de
aplicacin pero en realidad es un protocolo de transporte que se usa para trfico
de aplicacin en tiempo real (RTP), protocolo de capa de transporte (UDP),
protocolos de red (IPv4) y protocolos de capa de enlace y capa fsica
(Ethernet).
Debido a esto el trfico que se va a manejar es del tipo UDP, cuando se

hace uso de software para el anlisis de protocolos al momento de hacer una
llamada IP los paquetes que se muestran son de este tipo, y tienen diferente
tamao segn el codec que se utilice, esto se da debido a que cada codec utiliza
un distinto tamao de frame y transmite cierta cantidad de paquetes por
segundo.
3.1.1.1.
Protocolo RTP
El protocolo RTP (Protocolo de Tiempo Real) est definido dentro de los

estndares de la IETF especficamente en la recomendacin rfc3550 de julio
del 2003, que es la ltima versin de esta recomendacin en la cual describe a
este protocolo de transporte.
Este provee funcionalidades de extremo a extremo usadas para aplicaciones

como audio video y simulacin de datos, cabe recalcar que este no hace reserva
85
PAUL QUITO
de recursos ni tampoco garantiza calidad de servicio, fue diseado para que

trabaje independientemente del protocolo de transporte de la capa inferior ya
que puede trabajar bajo UDP como TCP, pero lo recomendable es que trabaje
sobre UDP ya que sobre TCP es un protocolo no apto para aplicaciones de en
tiempo real.
Una funcionalidad de este protocolo es que soporta transmisiones a varios

destinos, si el protocolo de la capa inferior trabaja con multicast, dentro de las
caractersticas cuenta con nmeros de secuencia lo que ayuda al receptor a
reconstruir la secuencia de datos.
Un caracterstica de este protocolo es que cuando se realiza una video

conferencia (audio y video) cada tipo de datos se separa en distintas sesiones,
lo que hace que ocupen diferentes puertos para transmitir los datos, esto tiene
un motivo ya que en transmisiones multicast los participantes pueden elegir el
medio que deseen ya sea solo audio, video o ambos.
3.1.1.1.1.
Estructura de cabecera del Protocolo RTP
La cabecera de un paquete consta de varios segmentos que definen

distintos valores como funcin, extensin de cabecera, el tipo de carga del
paquete entre otros, la estructura cuenta con la siguiente distribucin.
Fig. 3-1 Formato de Cabecera RTP
86
PAUL QUITO
Cada casillero representa un parmetro dentro de la configuracin del

paquete:
V = este parmetro corresponde a la versin de RTP que se est utilizando,

por defecto el valor es 2 ya que para versiones anteriores es 1 o 0 pero estos ya
estn en desuso.
P = si est este valor en 1 indica que en el paquete contiene bits de relleno,

en el espacio de carga, el ultimo octeto de relleno indica cuantos octetos deben
ser ignorados incluyndose, algunas veces esto es ocupado en algoritmos de
encriptacin.
X = si esta activado indica que existe una extensin de la cabecera.
CC = Contiene el numero de identificadores CSRC que le siguen a la

cabecera
M = este campo se conoce como de marcador ya que funciona mediante la

ejecucin de perfiles, lo que permite realizar algunas acciones ya predefinidas
como que los lmites de la trama sean marcados en el total del paquete.
PT = indica el formato de la carga RTP y determina su interpretacin por la

aplicacin.
Numero de Secuencia = este debe incrementar en uno cada vez que se

enva un paquete, el nmero inicial debe ser aleatorio para evitar ataques y
hacer la encriptacin ms segura
Timestamp = refleja el instante del primer octeto del paquete RTP. Esta
marca de tiempo se utilizar para poder medir el Jitter, adems que permite la
sincronizacin.
87
PAUL QUITO
SSRC = Identifica la fuente de sincronizacin, se lo escoge aleatoriamente

para que dos secuencias RTP del mismo origen no tengan el mismo SSRC
CSRC = Identifica las fuentes que contribuyen a la carga del paquete,

pueden ser de 1 a 15 items.
3.1.1.2.
Protocolo UDP
El protocolo UDP (protocolo de datagramas de usuario) est definido en

los estndares de la IETF especficamente en la recomendacin rfc0768, tiene
como protocolo de capa inferior al protocolo IP, siendo un protocolo de
transporte aporta procedimientos para que los programas de aplicacin puedan
enviar mensajes entre ellos.
Este no garantiza entrega ni duplicados de los paquetes, si la aplicacin en

uso necesita la comprobacin de la entrega de paquetes este protocolo no puede
ser implementado en esa aplicacin.
3.1.1.2.1.
Estructura de cabecera del Protocolo UDP
Dentro de la cabecera de un paquete UDP consta de cuatro campos que

definen a un paquete, estos campos definen los puertos de inicio y origen de un
paquete
El formato de este protocolo es el siguiente:
Fig. 3-2 Formato de Cabecera UDP
88
PAUL QUITO
Puerto de Origen = como su nombre lo indica el puerto del proceso emisor,

este depender de la aplicacin ya que cada aplicacin utiliza ciertos puertos
determinados, en este caso el puerto que comnmente se utiliza es 5060, y si no
existe otra informacin se asume que es el mismo puerto al cual debe llegar, en
ausencia del valor del puerto de origen se toma como valor 0.
Puerto Destino = el puerto a donde la informacin apunta como destino.
Longitud del Datagrama = representa la longitud de octetos de este

datagrama en el cual se incluye cabecera y datos.
Checksum = Es la suma de comprobacin de errores del mensaje
Payload = en este campo est el paquete RTP previamente analizado con la

informacin de voz.
3.1.1.3.
Protocolo IPV4
El protocolo IPV4 est definido dentro de los estndares de la IETF

especficamente en la recomendacin rfc791 de septiembre de 1981, fue
diseado para que proporcione los medios necesarios para la transmisin de
datagramas desde el origen al destino considerando que estos cuentan con una
direccin de longitud fija, entre sus funciones tambin est la de fragmentacin
y re ensamblaje de datagramas de mayor longitud para su transmisin.
Este protocolo tiene dos funciones las cuales son direccionamiento y

fragmentacin, usan las direcciones que se encuentran en su cabecera para
transmitir el datagrama a su destino, adems utilizan campos en la cabecera
para fragmentar y re ensamblar los datagramas cuando se da el caso que se
transmite por redes de trama pequea.
89
PAUL QUITO
Se cuenta con mdulos en cada punto ya sea de los Host o equipos

intermedios utilizados los cuales tienen reglas comunes que interpretan los
distintos campos de direccionamiento y para fragmentar y ensamblar los
datagramas.
Utiliza cuatro mecanismos para prestar su servicio, los cuales son:
Tipo de Servicio
Tiempo de Vida
Opciones
Suma de Control de Cabecera
El tipo de servicio se refiere a la calidad de servicio deseado, es un

conjunto de parmetros que sirven para seleccionar el tipo de servicio que se
dar al paquete segn las capacidades de la red.
Tiempo de vida: es el lmite de vida de un datagrama, es fijado por el

remitente y a cada salto de su ruta este va disminuyendo, si llega a cero antes
que el paquete llegue a su destino este se desecha.
Opciones: dan funciones de control en casos especiales pero no tal

necesarias en las transmisiones ms comunes, estas comprenden recursos para
marcas de tiempo, seguridad y encaminamiento especial.
Suma de control de Cabecera se lo usa en la verificacin de que el

datagrama fue transmitido correctamente, si esta suma de cabecera falla indica
que el paquete contiene errores por lo cual se descarta.
90
PAUL QUITO
3.1.1.3.1.
Funciones del Protocolo IPV4
3.1.1.3.1.1.
Direccionamiento
Esta funcin es muy importante porque define las distintas clases, ya que se
tiene cinco clases de direccionamiento, todas cuentan con dos partes
principales, la primera hace referencia a la red, y la segunda hace referencia al
host.
Las direcciones son de longitud fija cuentan con 4 octetos que suman 32
bits y se clasifican en:
Clase A
Clase B
Clase C
Clase D
Clase E
En la clase A el Bit ms significativo es el 0, luego esta seguido por 7 bits

que forman la red, y por ultimo por 24 que forman la direccin local que en
este caso serian los distintos host.
En la clase B los Bits ms significativos son 10 luego estn seguidos por 14

bits que forman el campo de red, y se tiene 16 bits que forman la direccin de
local.
En la clase C los Bits ms importantes son 110 seguidos por 21 bits que
forman la direccin de red, y los 8 restantes forman la direccin local o de
host.
91
PAUL QUITO
La clase D y E no son de uso comn en el primer caso los Bits ms

importantes son 1110 y el resto de bits identifica un grupo de multicast, en el
caso de la clase E los Bits ms significativos son 11110 y el resto de bits (27)
estn reservados para usos futuros.
Fig. 3-3 Clases de direccionamiento IP
3.1.1.3.1.2.
Fragmentacin
Esto es necesario cuando los paquetes se originan desde redes
que
permiten tamaos de paquetes grandes pero en el camino a su destino deben

atravesar una red que permite paquetes de tamao inferior, si en un caso al
paquete se lo marca como no fragmentar este no ser fragmentado en ningn
momento de su trayecto, pero si en su camino o en el destino es necesario una
fragmentacin este paquete ser descartado.
En receptor se usa el campo de identificacin para garantizar que no se

mezclen fragmentos de distintos datagramas, en el campo de posicin indica el
lugar de cada fragmento en el datagrama original.
Cuando se hace una fragmentacin se lo hace mnimo de 8 octetos para el

primer fragmento, el segundo puede no ser mltiplo entero de 8 octetos, estos
dos nuevos datagramas tienen cabeceras iguales.
92
PAUL QUITO
El campo de longitud total se marca con el tamao total del datagrama

inicial, en el campo de ms fragmentos para el caso anterior se coloca en 1.
Para re ensamblar el modulo en el host de destino toma todos los

fragmentos que contengan el mismo valor de los cuatro campos principales:
identificacin, origen, destino y protocolo.
3.1.1.3.2.
Estructura de cabecera del Protocolo IPV4
En la cabecera del protocolo IPV4 constan varios parmetros que definen

el comportamiento de un datagrama, entre los cuales estn los que permiten la
fragmentacin de un datagrama, y su posterior re ensamblaje, adems de los
casilleros en los que constan los valores para direccionamiento; la cabecera
est estructurada de la siguiente manera:
Fig. 3-4 Formato de cabecera IP
Versin, define el formato de cabecera, en este caso es la versin 4.
IHL, es la longitud de la cabecera que se multiplica por 32bits ya que el

mnimo tamao de la cabecera debe contar con los datos de las primeras 5 fila.
TOS, este valor se asigna para dar en cierta manera un valor que identifica
el tratamiento de un paquete, en la aplicacin que se est estudiando Asterisk
93
PAUL QUITO
maneja la asignacin de este valor para que los paquetes tengan cierta prioridad
en todo el trayecto, puede tomar los siguientes valores:
Bits 0-2 =Prioridad.

Bit
3: 0 = Demora Normal,
1 = Baja Demora.
Bit
4: 0 = Rendimiento Normal, 1 = Alto rendimiento.
Bit
5: 0 = Fiabilidad Normal, 1 = Alta fiabilidad.]
Bits 6-7 = Reservado para uso futuro.
Longitud total, es la longitud total del datagrama (cabecera y datos) que se

mide en octetos, el tamao normal de un paquete es de 576 octetos en los que
se incluyen 512 de datos y 64 de cabecera.
Identificacin, este valor se lo enva desde el origen como una ayuda para
re ensamblar el paquete original.
Indicadores, son indicadores de control, se usan para describir si el paquete

debe o no ser fragmentado.
Offset de Seguimiento, este indica a que parte del datagrama corresponde

el fragmento.
Tiempo de Vida, indica el valor de tiempo mximo que el datagrama va a

permanecer en movimiento, a medida que es procesado en cada modulo
durante todo su trayecto este disminuye por lo menos en 1 segundo hasta que
llega a cero y el paquete si no llego a su destino se descarta.
Protocolo, indica el protocolo usado en el siguiente nivel, estos son

representados por ciertos valores previamente asignados
94
PAUL QUITO
Suma de control de Cabecera, este valor se usa para verificar que el

paquete llegue integro a su destino, los valores que se utilizan cambian pero
solo el valor de tiempo de vida y a cada momento se vuelve a calcular.
Direccin de origen, cuenta con el valor de direccin desde donde se enva

el paquete puede ser de distintas clases.
Direccin de destino, contiene el valor de direccin final del paquete.
Opciones, este casillero lleva datos de que pueden ser implementados o no,
pero que deben estar en todos los mdulos, entre estas estn opciones de
seguridad, encaminamiento, registrar ruta entre otros.
Relleno, se utiliza para garantizar que la cabecera tenga un tamao

mltiplo de 32 bits y su valor es cero.
3.1.1.4.
Protocolo Ethernet
Definido por el grupo de trabajo de la IEEE 802.3 en el cual constan varios

estndares que definen velocidad, distancia mxima de funcionamiento, entre
otros, este protocolo tiene una trama definida de la siguiente manera:
Fig. 3-5 Formato de Trama Ethernet
Prembulo, es un conjunto de 64 bits que se alternan en uno y ceros con la

finalidad de sincronizar los nodos de recepcin.
95
PAUL QUITO
Direccin de destino, contiene la direccin fsica de destino.
Direccin de origen, contiene la direccin fsica de origen.
Campo tipo, este identifica el tipo de datos que se estn transmitiendo, con
la finalidad de en cierta forma determinar el modulo de software para tratar la
trama.
El paquete IPV4, consta en s de todos los datos procesados anteriormente

en las distintas capas.
CRC, sirve para verificar si la trama se transmiti correctamente ya que se

computa este valor y se lo compara con el que se genera al origen, para
comprobar que todos los datos estn correctos.
3.1.1.5.
Migracin de IPv4 a IPv6
Dentro de lo que significa una migracin de este tipo se debe tener en

cuenta las diferencias entre estos dos protocolos, debido a esto los colocamos
en el siguiente cuadro.
IPv4
IPv6
Direcciones de 32 bits
Direcciones de 128 bits
Direcciones Broadcast
Sustituidas por Direcciones

multicast
Notacin decimal
Notacin Hexadecimal
4 mil millones de direcciones
16 trillones de direcciones
Compatibilidad IPSec Opcional
Compatibilidad IPSec Obligatoria

(para seguridad)
96
PAUL QUITO
QOS solo mediante el Tipo de
QOS Mediante Etiqueta de Flujo y
Servicio, pero no se implementa
Clase de trfico, implementado
Fragmentacin posible en los host
Fragmentacin posible solo en los
y enrutadores
host
Se hace necesario NAT debido a la
En teora el NAT ya no se necesitara
cantidad de dispositivos
debido a que existiran suficientes

direcciones IP
Estas son algunas de las diferencias ms marcadas entre estos protocolos,

pero cuando hablamos de una migracin existen ciertos mecanismos que se
utilizan para realizar dicho proceso, entre los cuales tenemos:
Mecanismos de tipo Tnel, se basa en el encapsulamiento de un

protocolo en otro
Mecanismo de Traduccin, como su nombre lo indica traduce un

formato a otro
Dentro de la aplicacin al momento se est trabajando en una nueva

versin de Asterisk compatible con IPv6 la cual ya tiene sus primeros
lanzamientos pero estos se encuentran en fase de prueba, en cuanto a las
terminales en la actualidad solo dos marcas poseen terminales listas para IPv6
pero su costo no justifica la inversin, de igual manera los softphones tambin
estn empezando a implementar soporte para el nuevo protocolo pero por el
momento solo se encuentra uno que ya lo soporta, debido a la demanda futura
los fabricantes lanzaran al mercado nuevas actualizaciones para sus equipos ya
que casi el 100% de estos son actualizables.
97
PAUL QUITO
3.1.1.6.
Respuesta de la Red
Dentro del anlisis de la red de Amadeus se debe tener presente que esta
red no es de su uso exclusivo ya que pertenece a Megadatos SA, por lo que es
compartida por varios clientes, la respuesta de esta red depender de la hora, y
del sector ya que existen horas pico y centros de mayor densidad como son en
el caso de Guayaquil la plaza San Francisco, y en el caso de Quito el sector de
la Av. Amazonas.
Los valores que influyen dentro de la calidad de servicio para VOIP van a
tener una tendencia de cambio brusco si no se toman en cuenta parmetros para
garantizar que estos no superen los valores mximos, los mtodos ms
utilizados para brindar calidad de servicio se estudiarn en el siguiente
apartado.
La mejor manera para analizar el comportamiento de estos sectores es

mediante pruebas de campo ya que solo as se puede verificar cuan
congestionada se encuentra la red, mediante el uso de software para simular
una llamada IP se puede obtener ndices reales de Jitter, perdida de paquetes, y
latencia, y separar de manera efectiva las reas en donde se necesita un mayor
control para garantizar un cierto grado de calidad.
En el caso particular de estas dos ciudades (Quito y Guayaquil) como ya

se mencion se tiene una estructura de Metro Ethernet, la cual maneja como
puntos finales LRE, el uso de estos dispositivos puede hacer que vare en gran
medida los ndices ya mencionados debido que para cada caso en particular se
crean perfiles con la finalidad de aumentar la potencia o disminuirla
dependiendo cun lejos se encuentren los clientes del nodo, esto causa un
aumento o disminucin de la latencia y tambin se ve incrementado la prdida
de paquetes.
98
PAUL QUITO
Debido a todos estos factores se vio la necesidad de realizar pruebas de

campo y as tener una medida palpable del estado de la red, estas pruebas
tambin ayudan a comprobar si el proveedor de servicios est cumpliendo con
lo estipulado en el contrato.
3.1.2. Mtodos para la medicin de parmetros de QOS
Como se hablo en captulos anteriores los parmetros que rigen la calidad

de servicio son la Latencia, Jitter y Prdida de Paquetes, estos parmetros,
pueden ser calculados, o tambin existe en el mercado software para su
medicin, entre los mtodos para el clculo de estos parmetros tenemos:
Un mtodo desarrollado en conjunto por la Universidad Tecnolgica de

Per y la Universidad Complutense de Madrid, se basa en tomar informacin
de un punto de acceso en este caso un Router, de este equipo, se obtiene
mediante el protocolo SNMP los valores de las variables de MIB, estas son:
3.1.2.1.
Retardo
Se hace una prueba enviando cada cinco minutos 4 paquetes de prueba

mediante el uso del comando ping, del cual se obtiene un tiempo promedio
de vida de ida y vuelta del paquete de donde para obtener una media se usa la
siguiente frmula:
99
PAUL QUITO
En donde n representa el nmero de muestras que se enviaron.
3.1.2.2.
Prdida de paquetes
Para la medicin de prdida de paquetes se consideran paquetes

descartados, paquetes con errores o paquetes de protocolos desconocidos que al
no ser reconocidos son descartados, para el clculo de este valor se toman las
siguientes variables MIB
Para paquetes perdidos se suman:

Interfaces.ifTable.ifEntry.ifinDiscards.ifIndex +
Interfaces.ifTable.ifEntry.ifinErrors.ifIndex +
Interfaces.ifTable.ifEntry.ifOutUnknownProtos.inIndex
Para paquetes entrantes se suman:
Interfaces.ifTable.ifEntry.ifinUcastPkts.ifIndex +
Interfaces.ifTable.ifEntry.ifinNUcastPkts.ifIndex
El clculo de este valor se representa en porcentaje, la medicin se hace a

intervalos de 5 minutos y su frmula est dada de la siguiente manera,
El valor de n representa el instante de muestreo.
100
PAUL QUITO
3.1.2.3.
Jitter
Para el clculo de Jitter no se puede aplicar los valores de este mtodo ya

que como se sabe el Jitter es el tiempo de llegada entre paquetes que muy
posiblemente siguen distintos caminos, y debido que los parmetros MIB solo
actan sobre un Router no se hace factible la medicin de este valor,
determinar el Jitter se debe hacer en el punto de llegada del paquete, para su
clculo se consideran dos paquetes y esta dado por la siguiente frmula:
En donde:
I es el primer paquete
I-1 Es el paquete anterior
D es la diferencia
J el segundo paquete
3.1.2.4.
MOS
Otro factor que se utiliza en el clculo de calidad de servicio es el valor del

MOS que si bien es un valor subjetivo basado en la opinin de personas que
escuchan ciertas muestras de audio, actualmente se lo calcula en base a varios
modelos entre ellos estn:
PSQM (ITU P.861) / PSQM+

MNB (ITU P.861)
PESQ (ITU P.862)
PAMS (British Telecom)
E-model (ITU G.107)
Algunos de ellos estn en desuso pero otros aun se los utiliza como es el
caso del E-Model que es el ms utilizado, este fue desarrollado por la ITU,
101
PAUL QUITO
pero presenta ciertas fallas en su implementacin, esto se que mejor con otros
modelos como el PESQ que data del ao 2001, igualmente desarrollado por la
ITU, actualmente se estn probando otros modelos que estarn disponibles en
los siguientes aos.
PSQM, PSQM+, MNB, y PESQ parten del mismo algoritmo (ITU P.861),
PAMS fue desarrollado por British Telecom, estos proporcionan valores
similares, y lo que hacen es comparar seales partiendo de una seal de
referencia con la seal que llega al receptor, sin embargo no son los apropiados
al tratarse de una red de paquetes ya que estn basados en la redes telefnicas
antiguas por lo cual no pueden adaptarse correctamente a problemas de
latencia, jitter, y prdida de paquetes.
Debido a esto la ITU recomienda el uso del E-Model, el cual arroja un

valor llamado el factor R, este valor vara entre 1 y 100, se lo compara con el
MOS mediante la siguiente estimacin:
Fig. 3-6 Equivalencia entre Factor R y MOS
102
PAUL QUITO
Este modelo tiene una formula aparentemente sencilla, pero cada

parmetro de esta frmula depende de muchos valores tomados de la red, la
frmula est dada por:
En donde:
Ro. Es el Efecto del ruido
Is. Es el conteo para una conexin fuerte y cuantizacin
Estos son puramente factores que dependen de la seal de voz no

contemplan efectos de la red.
Id e Ie. Capturan el efecto del retraso y distorsin de la seal
El valor de Id esta dado como un efecto del retraso, de este depende el eco.
El valor de Ie est dado por la captura de la distorsin de la voz original

debido a un codec y de la prdida de paquetes tanto en la red como en el buffer,
este valor depende bastante si se utiliza o no un algoritmo PLC, el cual se usa
para disminuir el efecto de la perdida de paquetes, estos algoritmos estn
presentes en codecs como G729 tambin en el codec G723.1 en los cuales al
ser de alta compresin son sensibles a la prdida de paquetes.
En conclusin este es un modelo bueno pero no lo suficiente para los

constantes cambios de condiciones de las redes actuales, esto se ve evidenciado
en varios estudios en los cuales se muestra como los valores de MOS basados
en esta frmula no son los correctos como lo demostr un estudio realizado por
la universidad de Tsukuba en conjunto con los laboratorios de AT&T debido a
esto se proponen nuevos modelos como es el PESQ, que se ajuste de mejor
103
PAUL QUITO
manera a la realidad actual de las redes de conmutacin de paquetes, este

cuenta tambin con un rango de valores que va desde -0,5 hasta 4,5
Hasta el momento el modelo que domina el mercado es el E-Model, ya que

est presente en algunos de los programas para medir la calidad de servicio,
como es el caso de Chariot de la empresa NetIQ, la empresa Telchemy tambin
en su software para medir la calidad del servicio implementa el algoritmo del
E-Model.
3.1.2.5.
Software para medicin de QOS
En el mercado tambin existe software dedicado especialmente para la

medicin de estos factores tan importantes para el despliegue de una red VOIP,
mediante el uso de esta herramienta se puede analizar cmo se encuentra una
red, en qu puntos se debe actuar para que pueda manejar sin problemas el
trfico de voz, y as poder desplegar sin inconvenientes antes de realizar
inversiones en equipamiento.
El software que se us para medir estos valores fue My Speed Server de

la empresa VisualWare, el cual nos muestra los valores de jitter, latencia,
perdida de paquetes y MOS, esta aplicacin consiste en colocar un servidor en
el nodo en el cual va a implementar la aplicacin de VOIP, y desde los distintos
puntos hacer una prueba accediendo a este servidor, y simulando una llamada,
dependiendo del codec que se desee utilizar, este parmetro y muchos ms se
pueden cambiar dentro de las configuraciones del servidor.
104
PAUL QUITO
Fig. 3-7 My Speed Server, Software para medicin de Calidad de servicio VOIP
Tambin nos muestra un valor de calidad de servicio el cual es calculado a

partir de la una formula muy sencilla
El valor de MOS es posiblemente calculado por medio del E-Model, ya que

es el ms usado en el medio, luego de consultar a la compaa acerca del
algoritmo usado sta respondi que esa informacin no se puede suministrar
debido a que es propiedad intelectual de la empresa, pero que est basado en la
perdida de paquetes y jitter.
Al momento de ingresar al servidor y realizar una prueba se despliega una

aplicacin en Java en la cual solo se debe aceptar para que empiece la prueba
Luego de realizar una prueba se obtienen los resultados en el siguiente

formato:
105
PAUL QUITO
Fig. 3-8 Formato de resultado de My Speed Server
Como se puede observar nos muestra los valores de jitter, latencia, perdida
de paquetes con lo cual podemos hacer mejoras en la red para tener en ptimo
estado el sistema.
3.1.2.6.
Protocolos de QOS
Dentro de los lineamientos que se siguen para aplicar calidad de servicio se

describen los siguientes:
3.1.2.6.1.
Protocolo de Reserva de Recursos: RSVP (Servicios Integrados).
Protocolo de Servicios Diferenciados (DiffServ) y TOS.
MPLS.
RSVP
Permite que los programas que trabajan en Internet tengan una calidad de
servicio para su flujo de datos, es un protocolo nuevo que est en fase de
normalizacin por parte de la IETF, descrito en el documento RFC2205 en su
versin 1 de septiembre de 1997, este protocolo es usado por un host para
pedir cierta calidad de servicio a la red en especial en aplicaciones que
demandan cierta cantidad de flujo de datos, tambin es utilizado por los routers
para brindar calidad de servicio a lo largo del trayecto, cuando se hace una
106
PAUL QUITO
peticin este protocolo reserva recursos a lo largo de todos los nodos en el

trayecto, est al nivel de un protocolo de ruteo, pero no es un protocolo de ruteo
ya que est diseado para funcionar con los protocolos de ruteo unicast y
multicast.
En el caso de unicast el host hace una peticin y consulta a la base local de

datos sobre las tablas de ruteo para obtener la ruta.
En el caso de multicast manda mensajes IGMP para unirse a un grupo

multicast luego manda peticiones RSVP a lo largo del trayecto para reservar
los recursos necesarios.
Este consta de dos partes el Modulo de Control de Admisin y el modulo

de Control de Poltica. El primero se encarga de verificar si existen los recursos
en el nodo para satisfacer las necesidades; el modulo de Control de Poltica se
encarga de verificar si el solicitante tiene los permisos necesarios, este
procedimiento lo hace en cada nodo hasta llegar a su destino y si en alguno de
ellos no existe la capacidad para cumplir cualquiera de estas dos condiciones
regresar un mensaje de error.
Cuando se hace una peticin el protocolo enva a todos los puntos mensajes
para que se mantenga activo la reserva de recursos, al faltar estos mensajes la
reserva de recursos se elimina y los nodos pasan a la condicin anterior a la
peticin RSVP, este protocolo es simplex solo reserva recursos en la direccin
de quien hace la peticin como se muestra a continuacin:
107
PAUL QUITO
Fig. 3-9 Funcionamiento del Protocolo RSVP
Una sesin RSVP est compuesta por tres parmetros los cuales son:
Direccin de Destino
Identificacin de Protocolo
Puerto de destino
Una reservacin de recursos consiste en dos partes: flujo esperado y filtro

esperado, estas dos partes en conjunto son conocidas como descriptor de flujo,
el primero especifica la calidad de servicio deseada, el filtro esperado junto con
la especificacin de sesin define el grupo de paquetes o flujo de datos que van
a recibir la calidad de servicio, el flujo esperado es utilizado para establecer
parmetros en los nodos, en cambio el filtro esperado establece parmetros en
el clasificador de paquetes, los paquetes que no estn dentro del conjunto a
aplicar calidad de servicio son tratados con la regla del mejor esfuerzo.
108
PAUL QUITO
En cada nodo los datos son tratados de la siguiente manera:
Fig. 3-10 Funcionamiento del Protocolo RSVP a nivel de Router
3.1.2.6.2.
MPLS
Este protocolo es una solucin
verstil a los problemas actuales que
presentan las redes de paquetes conmutados, como son velocidad, escalabilidad

y lo ms importante manejo de calidad de servicio, este protocolo nace como
una alternativa para el manejo de los backbone basados en el protocolo IP, la
ventaja es que puede existir sobre redes ATM y Frame Relay, debido a esto
MPLS ocupara un lugar importante en el ruteo, conmutacin de las prximas
redes de datos.
Dentro de las caractersticas del protocolo MPLS estn:
Especifica mecanismos para el manejo de distintos flujos ya sea

flujo entre distinto hardware, maquinas, hasta flujo entre distintas
aplicaciones.
Es independiente de los protocolos de capa 2 y capa 3.
Compatible con el protocolo RSVP
Soporta IP, ATM, Frame Relay
109
PAUL QUITO
En esencia se basa en colocar valores de cabecera ms sencillos para

aminorar el tiempo de procesamiento ya que actualmente un paquete al llegar a
un Router este cambia de cabecera para continuar al siguiente punto, ac se
define con identificadores que hacen que el paquete vaya de un punto al otro
por una ruta prefijada
Consta de:
LER es el elemento que inicia y termina el tnel, son los ruteadores de
entrada y salida, que estn en los extremos de la red
LSR este elemento conmuta las etiquetas y se encuentra en el ncleo de la

red, son los Router de conmutacin.
LSP este elemento es el camino MPLS en otras palabras el tnel que sigue
a lo largo del trayecto, y son establecidos ya sea antes de la transmisin de
datos o por la deteccin de flujo de datos.
LDP es el protocolo de distribucin de etiquetas
FEC es el trfico que se encamina bajo una etiqueta, es decir es el conjunto

de paquetes que comparten los mismos requerimientos de transporte en este
caso su etiqueta.
Las etiquetas estn encapsuladas en la capa 2, y estas se manejan entre los

LSR ya que las etiquetas son validas solo entre estos, esto es parecido a lo que
sucede en Frame Relay con los DLCI y con los VPI y VCI en el caso de las
redes ATM
Para el asignar las etiquetas se pueden basar en ciertos criterios como:
Destino del trafico Unicast
Destino del trafico Multicast

110
PAUL QUITO
Ingeniera de Trfico
Uso de VPN
Calidad de servicio
El formato genrico para una etiqueta MPLS est dado de la siguiente

estructura:
Fig. 3-11 Formato genrico de cabecera el protocolo MPLS
Para generar un LSP se lo puede hacer en base a dos opciones:
Salto a salto en este esquema cada LSR independientemente selecciona el

siguiente salto para una FEC en particular, este mtodo es parecido al usado
ahora en las redes IP
Ruteo Explcito, en este el LSR del borde donde llegan los datos
inicialmente genera un trayecto a travs de toda la nube MPLS, reservando
recursos para este trfico, lo que da medio para brindar calidad de servicio.
Un LSP es unidireccional por lo cual para el trfico de regreso se debe

crear otro LSP.
111
PAUL QUITO
3.1.2.6.2.1.
Operacin del protocolo MPLS
Para que un paquete viaje por una red MPLS se dan los siguientes pasos:
Creacin y distribucin de etiquetas

Creacin de tablas en cada Router
Creacin del trayecto para la conmutacin de etiquetas
Insercin de etiqueta y bsqueda en las tablas
Reenvo de paquete
Fig. 3-12 Operacin de Protocolo MPLS
3.1.2.6.3.
Protocolos de Servicios Diferenciados (DiffServ) y TOS
En este protocolo los paquetes son marcados y clasificados para recibir un

trato especial en cada salto, esto es implementado en los bordes de red o en los
host, este protocolo segn el servicio y prioridad coloca en el octeto del TOS
un valor que define la prioridad del paquete.
Este protocolo fue pensado para generar el menor gasto posible ya que al
aplicarse en los extremos no se necesita la implementacin en todos los puntos
de la red.
112
PAUL QUITO
Dentro de un paquete IP el octeto TOS tiene la siguiente distribucin:
Fig. 3-13 Posicin del octeto TOS en un paquete IP
Este campo de de 6 bits tiene un patrn especfico llamado cdigo DS, el

cual indica la manera en que cada Router debe tratar al paquete, puede tener
hasta 64 valores binarios, aparte de los 6 bits tenemos 2 bits ms que completan
el octeto que estn reservados para aplicaciones futuras.
Las configuraciones estndar hasta ahora son las siguientes:
De comportamiento por defecto, en el cual los valores son cero y el

paquete no recibe tratamiento especial
Por seleccin de clase de comportamiento, este funciona desde

001000 hasta 111000, los cuales definen 7 comportamientos, cada
uno tiene mayor probabilidad de envo.
Por comportamiento de re envo acelerado su valor por defecto es

101110 y su funcin es que la cola que se genera por el flujo sea
casi siempre cero
113
PAUL QUITO
Por comportamiento de re envo asegurado consiste en si en 3 sub

comportamientos, en los cuales cuando existe congestionamiento de
red y est marcado con AF1 (primer comportamiento) tienen menor
probabilidad de ser descartado.
La estructura de servicios diferenciados la componen nodos interiores y de

frontera en los cuales en todos ellos se debe poder aplicar los diferentes
tratamientos a cada paquete.
Fig. 3-14 Estructura de funcionamiento por DiffServ
114
PAUL QUITO
3.1.3. Anlisis y simulacin
3.1.3.1.
Anlisis de la red Amadeus Guayaquil
Como ya se explico en el captulo anterior la red Amadeus en la ciudad de

Guayaquil en su mayora est concentrada en un solo nodo en el sector de la
plaza San Francisco, los clientes restantes ingresan por los nodos alternos de
los proveedores externos.
Se hicieron pruebas utilizando el software My Speed Server para

determinar el estado de la red debido a que esta red es compartida por varios
clientes de Ecuanet, se procur que los clientes estn distribuidos de la mejor
manera en todos los nodos para tener una visin general del estado de la red.
Se visitaron 16 clientes de los cuales 10 se conectan al nodo SF, 4 ingresan

por el nodo FR1, 1 por el nodo FR2 y el restante por el nodo FR3, las pruebas
se hicieron en las horas de 10 a 12am y durante horas de la tarde de 2 a 4pm
horas de mayor trfico, esto se lo hizo con la finalidad de poner a prueba la
capacidad para funcionamiento de manera paralela entre la aplicacin
Amadeus, navegacin Web y una llamada IP, el detalle de la ubicacin de estos
clientes se adjunta en el Anexo 2 esquema 1; los resultados que se obtuvieron
son los siguientes:
115
PAUL QUITO
Datos Pruebas Guayaquil
Date/Time
27/12/2007 10:40
27/12/2007 10:54
27/12/2007 11:49
27/12/2007 12:15
27/12/2007 12:30
27/12/2007 12:43
27/12/2007 12:56
27/12/2007 13:08
27/12/2007 13:18
27/12/2007 13:32
27/12/2007 13:39
27/12/2007 14:33
27/12/2007 14:46
27/12/2007 15:30
27/12/2007 15:43
27/12/2007 15:59
Download Upload
Cliente
bps
bps
American Tour
59,472
917,32
Coltur
188,944 488,288
Contiviajes
233,536 201,344
Delgado Travel
235,824 217,896
Dilontur
245,88
353,984
Ditursa
1,282,392 664,608
Golden Travel
131,096 104,088
GrandTours
155,032 2,514,496
Isaitur
3,595,080 2,872,216
Travelsur
61,312 1,688,464
Valtur
123,184 5,347,072
Royal Tour
703,488
480,88
Grupo Ecuatorial
594,144 699,336
Megatour
101,528 105,776
Euroexpreso
1,521,448 1,514,584
Delgado Travel G M
30,408
17,928
RTT
30
129
64
71
133
66
69
27
31
39
4
129
136
161
45
380
QOS
85
15
95
96
98
70
17
51
71
90
5
47
33
37
55
95
Jitter
3.5
0.0
2.3
0.3
3.6
0.0
6.9
0.0
7.3
4.1
0.0
1.3
0.0
4.2
3.3
3.7
% Loss
1.4
1.6
1.0
1.2
1.4
1.6
1.4
1.0
0.8
1.4
0.8
1.8
1.0
0.0
2.4
0.0
MOS
2.7
3.9
3.8
3.9
3.7
3.9
3.6
4.0
3.8
2.8
4.0
3.8
4.0
4.0
3.8
2.2
Tabla. 3-1 Pruebas en Guayaquil
116
PAUL QUITO
3.1.3.2.
Anlisis de la red Amadeus Quito
De igual manera que en el caso de Guayaquil se hizo pruebas en la

ciudad de Quito para hacer un sondeo del estado de la red, por el motivo
que en esta ciudad se encuentran un mayor nmero de nodos
pertenecientes, en total son 7 en los cuales estn repartidos los distintos
clientes Amadeus.
En este caso tambin se hizo uso del software My Speed Server, se

coloc el servidor en el Telepuerto que se encuentra en las oficinas
principales de Ecuanet.
Se hizo pruebas en 19 clientes todos estos dentro de los nodos de

Ecuanet ya que los clientes que se encuentran por medio de proveedores
externos no superan un nmero de 7 en total, se procur hacer las pruebas
de manera homognea para tener una visin lo ms acertada del estado de
la red, se hicieron durante dos das debido a la extensin que se deba
cubrir para los 7 nodos, el detalle de la ubicacin de los clientes se puede
apreciar de mejor manera en el Anexo 2 esquema 2 al 4.
Las pruebas se realizaron en horas pico de trfico, desde las 12 a 5pm

en el primer da, en el segundo da se hizo en horas desde las 10am a
12am y desde las 13 a 16pm, los datos obtenidos son los siguientes:
117
PAUL QUITO
Datos Pruebas Quito

Date/Time
12/12/2007 12:26
12/12/2007 12:32
12/12/2007 13:13
12/12/2007 15:02
12/12/2007 15:52
12/12/2007 16:28
12/12/2007 17:33
13/12/2007 10:39
13/12/2007 11:02
13/12/2007 11:32
13/12/2007 12:06
13/12/2007 12:35
13/12/2007 13:00
13/12/2007 13:07
13/12/2007 14:11
13/12/2007 15:02
13/12/2007 15:35
13/12/2007 15:59
13/12/2007 16:43
Clientes
Download bps Upload bps
Garlatour
85,88
22,64
Intercontinental
36,048
17,008
Interturis
86,472
43,848
Iberomundo
39,232
13,32
Absolut Joy
63,832
32,992
Maritetur
47,984
18,112
Intisaya
40,192
41,656
American Travelling
46,672
31,496
Intipungo
83,072
23,344
Palmarvoyages
89,336
33,144
La Moneda
90,448
59,344
Turismania
56,592
32,776
Fly Travel
42,64
33,576
Agentur
168,032
179,336
Seitur
302,96
230,6
Express Tour
36,424
30,704
Vacation Center
180,152
180,512
Flamingo Tours
43,248
36,12
Holiday
100,744
99,208
RTT
138
175
23
107
41
108
140
60
24
24
10
74
12
40
26
7
79
47
389
QOS
27
60
41
60
86
13
68
6
38
23
11
43
4
60
12
6
99
91
80
Jitter
3.8
3.9
3.4
10.2
1.7
8.2
4.8
3.5
4.0
3.9
2.1
3.5
4.0
3.6
7.8
2.0
3.7
6.5
4.6
% Loss
0.4
0.0
0.2
0.2
0.0
4.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
MOS
2.0
2.2
3.2
1.9
2.4
1.7
2.4
2.3
2.2
2.3
3.1
2.3
2.3
4.0
3.9
2.4
4.0
2.3
4.0
Tabla. 3-2 Pruebas en Quito
118
PAUL QUITO
3.1.3.3.
Simulacin red Amadeus Quito y Guayaquil
Para la simulacin de la red Amadeus se utiliz el software IT Guru

edicin acadmica, el cual tiene funcionalidades casi similares con la
versin comercial, salvo ciertos mdulos y opciones de los mismos, el
mayor inconveniente que se tuvo con este software es la limitacin de
eventos que puede registrar ya que como lmite tiene 50000000 de
eventos, segn la empresa este nmero es suficiente para una simulacin
de carcter educativo.
Dentro de los parmetros de simulacin se puede manipular el

nmero de repeticiones de los eventos como llamadas o peticiones para
navegacin.
Se diseo una estructura lo ms semejante a la realidad ya que ciertos

valores como el nmero de clientes, nombres y configuraciones no
pueden ser divulgados debido a que son de propiedad corporativa de
Ecuanet, por lo que se hizo una estimacin en base a la capacidad en
equipamiento instalado.
Se hizo distintas pruebas dentro de las cuales:
Simulacin de voz y datos de los clientes Amadeus dejando

de lado los clientes externos de Ecuanet
Simulacin incluyendo una estimacin de clientes Ecuanet.
Pruebas saturando los enlaces troncales entre nodos para as

simular un alto trfico de los clientes de Ecuanet.
No se logr alcanzar los ndices de trfico de los clientes de Ecuanet

debido a las limitaciones del software, al momento de intentar alcanzar
los niveles de trfico reales estos superan por mucho al nmero de
119
PAUL QUITO
eventos que puede registrar la versin estudiantil por lo cual el tiempo de

simulacin no supera los dos minutos y no se puede apreciar los distintos
cambios en la red
Dentro de la simulacin predominan dos bloques que son por as

decirlo los ms importantes ya que definen el comportamiento de las
aplicaciones as como el modo en el cual van a ser usadas las
aplicaciones, esto define la carga que va a tener la red.
Para esta simulacin se utiliz aplicaciones de correo, navegacin,

voz, para esto se defini servidores los cuales hacen posible que estas
aplicaciones reaccionen ante las peticiones de los clientes, para los
clientes Ecuanet se configuro el perfil de Investigador el cual combina la
navegacin de uso pesado y correo electrnico de uso liviano, se
implemento este perfil como secundario para los clientes Amadeus, y
como principal se utiliz el perfil de VOIP.
La configuracin que se utiliz para el perfil de investigador se la

hizo procurando que las repeticiones no se incrementen de manera
desmesurada
para
as
poder
apreciar
de
mejor
manera
el
desenvolvimiento de la red, para hacer esto se debi cambiar los

parmetros de repeticin que vienen por defecto, estos valores son:
120
PAUL QUITO
Fig. 3-15 Configuracin del perfil de Investigador
La configuracin que se utiliz para el perfil de VOIP se la hizo en

base a ejemplos presentados en el software as como en ejemplos que se
muestran en muchos sitios de internet, pero adaptados a la realidad de la
red y de la situacin actual de la central telefnica de Amadeus, la
duracin de las llamadas se hizo que no superen los 120 segundos pero
tampoco que sean menores de 80 segundos, sabiendo que en promedio se
tienen 8 y 6 llamadas por cada 45 minutos respectivamente en Quito y
Guayaquil segn la informacin proporcionada por Amadeus. En esta
simulacin se puso al sistema en una condicin poco probable de 15
llamadas aproximadamente en 30 minutos para as considerar un
crecimiento en el nmero de clientes para reproducir este escenario se
hizo cambios en la forma en la cual se repiten los eventos, la
configuracin del perfil fue:
121
PAUL QUITO
Fig. 3-16 Configuracin del perfil de VOIP
Las diferencias entre los perfiles se describen a continuacin:
Perfil Investigador
Aplicaciones:
Navegacin
Perfil VOIP
Web, Aplicaciones: Voip
Servicio de correo
Modo de operacin: Simultanea
Modo de operacin: Randmica
Tiempo entre repeticin: constante de Tiempo entre repeticin: exponencial

300sg
de 5000sg
Nmero de repeticiones: 5
Nmero de repeticiones: 1
Forma de Repeticin: Serial
Forma de Repeticin: Serial
Tabla. 3-3 Diferencias entre Perfiles
3.1.3.3.1.
Esquema de Simulacin red Amadeus Quito
Para la simulacin se consider los siete nodos que se encuentran

repartidos en la ciudad as como la manera en la cual estn
interconectados, por razones de seguridad se evitan los nombres, se
dividi a la red total en subredes, cada una de estas representa a un nodo,
en el esquema de simulacin se coloco dos bloques de aplicaciones y dos
bloques de perfiles, estos manejan aplicaciones de datos y voz, el
esquema de simulacin es el siguiente:
122
PAUL QUITO
Fig. 3-17 Esquema de Simulacin de la red de Quito
Dentro de cada subred el esquema de simulacin vara solo en el

nmero de clientes ya que los componentes principales no varan, estos
componentes son:
Switch.
Red de rea local para simular los clientes Ecuanet.
Terminales que simulan los puntos de la Red Amadeus.
En el Telepuerto principal es el nico nodo en donde cambia ya que

se agregan los servidores de Navegacin, Correo y SIP, la forma en la
cual est conectada es la siguiente:
Fig. 3-18 Esquema de Simulacin de una Subred
123
PAUL QUITO
3.1.3.3.2.
Esquema de Simulacin red Amadeus Guayaquil
Para esta simulacin se tomo en cuenta el nodo principal SF ya que

en este se encuentran en su totalidad los clientes Amadeus que ocupan el
backbone propio de Ecuanet, tambin se tomo en cuenta el nodo principal
y las oficinas de Amadeus, dentro del nodo SF se subdividi cada switch
como si fuese una subred, esto con el propsito de saturar los enlaces
entre switch para as simular un alto trfico de los clientes de Ecuanet
Fig. 3-19 Esquema de Simulacin de la red de Guayaquil
De igual forma el nico punto que cambia la configuracin es en el

Telepuerto principal, los elementos utilizados en las subredes son:
Switch.
Red de rea local para simular los clientes Ecuanet.
Terminales que simulan los puntos de la Red Amadeus.
124
PAUL QUITO
3.1.3.3.3.
Resultados Simulacin red Amadeus Quito y Guayaquil
Como se mencion anteriormente las simulaciones efectuadas fueron

de tres tipos:
Simulacin de voz y datos de los clientes Amadeus dejando

de lado los clientes externos de Ecuanet
Simulacin incluyendo una estimacin de clientes Ecuanet.
Pruebas saturando los enlaces troncales entre nodos para as

simular un alto trfico de los clientes de Ecuanet.
Los datos que se recolectaron comprenden el desempeo de la red

tanto en navegacin Web como en VOIP, los parmetros medidos son:
El tiempo de respuesta para pginas HTTP
Trfico HTTP enviado y recibido
Tiempo para el establecimiento de llamadas
Duracin de llamadas
Llamadas conectadas
Las grficas recolectadas comprenden un periodo de simulacin de

30 a 45 min para Quito y Guayaquil respectivamente, esto se dio debido a
la complejidad de las redes, principalmente por el nmero de usuarios.
125
PAUL QUITO
3.1.3.3.3.1.
Grficas Quito
Tiempo de respuesta para pginas HTTP
Fig. 3-20 Tiempo de respuesta HTTP Quito
Los valores promedios para los diferentes casos son:
RED_AMADEUS_CON_CARGA_SIP_DATOS 0.056sg
RED_AMADEUS_SIN_CARGA_SIP_DATOS 0.021sg
RED_AMADEUS_ECUANET_SIN_CARGA_SIP_DATOS
0.025sg
126
PAUL QUITO
Fig. 3-21 Trfico HTTP enviado Quito
RED_AMADEUS_CON_CARGA_SIP_DATOS
8841.5bytes/sec.
RED_AMADEUS_SIN_CARGA_SIP_DATOS
7649bytes/sec.
28629.27bytes/sec.
127
PAUL QUITO
Fig. 3-22 Trfico HTTP recibido Quito
Los valores promedios para los diferentes casos son iguales al

caso anterior
128
PAUL QUITO
Fig. 3-23 Tiempo de establecimiento de llamadas Quito
0.001985sg
129
PAUL QUITO
Duracin de llamadas
Fig. 3-24 Duracin de llamadas Quito
205.29sg
130
PAUL QUITO
Llamadas conectadas
Fig. 3-25 Llamadas Conectadas Quito
1,34
llamadas
1,30
llamadas
1,54 llamadas
131
PAUL QUITO
3.1.3.3.3.2.
Grficas Guayaquil
Tiempo de respuesta para pginas HTTP
Fig. 3-26 Tiempo de respuesta HTTP Guayaquil
0.026sg
132
PAUL QUITO
Fig. 3-27 Trfico HTTP enviado Guayaquil
6622.51bytes/sec.
6953.64bytes/sec.
18278.14bytes/sec.
133
PAUL QUITO
Fig. 3-28 Trfico HTTP Recibido Guayaquil
Los valores promedios para los diferentes casos son iguales al

caso anterior
134
PAUL QUITO
Fig. 3-29 Tiempo de establecimiento de llamadas Guayaquil
0.0021sg
135
PAUL QUITO
Duracin de llamadas
Fig. 3-30 Duracin de llamadas Guayaquil
201.15sg
136
PAUL QUITO
Llamadas conectadas
Fig. 3-31 Llamadas Conectadas Guayaquil
1,10
llamadas
1,09
llamadas
1,63 llamadas
137
PAUL QUITO
3.2. DETERMINACIN DE UNA CIUDAD COMO PROYECTO PILOTO
Luego de realizar las visitas en los distintos puntos tanto en Quito

como en Guayaquil la mejor opcin para iniciar un proyecto piloto es
Guayaquil.
Debido a las siguientes condiciones
Infraestructura que se maneja en esta ciudad, como se analiz

en secciones anteriores la distribucin de la red es mucho ms
sencilla ya que cuentan con dos nodos principales a los cuales
enlazan los clientes haciendo mucho ms simple el manejo de
trfico de los mismos.
Otro punto importante es el buen estado de los enlaces hacia

los clientes.
Un aspecto importante es por motivos de logstica ya que la

oficina central de Amadeus se encuentra en la misma ciudad,
haciendo mucho ms sencillo la implementacin de cualquier
cambio o solucin de problemas tcnicos.
Se la toma como primera opcin ya que tambin se podra

experimentar con otros clientes de otras ciudades, por ejemplo
Cuenca ya que el trfico generado se dirige a la nube de
Guayaquil.
138
PAUL QUITO

Capitulo 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capitulo 3

Cargado por

Copyright:

Formatos disponibles

CAPITULO 3 ESTUDIO DE TRFICO

CAPITULO 3 ESTUDIO DE TRFICO

3.1. ANLISIS DE TRFICO

Dentro de una llamada IP estn presentes el protocolo RTP, UDP, IP y

Debido a esto el trfico que se va a manejar es del tipo UDP, cuando se

El protocolo RTP (Protocolo de Tiempo Real) est definido dentro de los

Este provee funcionalidades de extremo a extremo usadas para aplicaciones

CAPITULO 3 ESTUDIO DE TRFICO

de recursos ni tampoco garantiza calidad de servicio, fue diseado para que

Una funcionalidad de este protocolo es que soporta transmisiones a varios

Un caracterstica de este protocolo es que cuando se realiza una video

Estructura de cabecera del Protocolo RTP

La cabecera de un paquete consta de varios segmentos que definen

Fig. 3-1 Formato de Cabecera RTP

CAPITULO 3 ESTUDIO DE TRFICO

Cada casillero representa un parmetro dentro de la configuracin del

V = este parmetro corresponde a la versin de RTP que se est utilizando,

P = si est este valor en 1 indica que en el paquete contiene bits de relleno,

X = si esta activado indica que existe una extensin de la cabecera.

CC = Contiene el numero de identificadores CSRC que le siguen a la

M = este campo se conoce como de marcador ya que funciona mediante la

PT = indica el formato de la carga RTP y determina su interpretacin por la

Numero de Secuencia = este debe incrementar en uno cada vez que se

CAPITULO 3 ESTUDIO DE TRFICO

SSRC = Identifica la fuente de sincronizacin, se lo escoge aleatoriamente

CSRC = Identifica las fuentes que contribuyen a la carga del paquete,

El protocolo UDP (protocolo de datagramas de usuario) est definido en

Este no garantiza entrega ni duplicados de los paquetes, si la aplicacin en

Estructura de cabecera del Protocolo UDP

Dentro de la cabecera de un paquete UDP consta de cuatro campos que

El formato de este protocolo es el siguiente:

Fig. 3-2 Formato de Cabecera UDP

CAPITULO 3 ESTUDIO DE TRFICO

Puerto de Origen = como su nombre lo indica el puerto del proceso emisor,

Puerto Destino = el puerto a donde la informacin apunta como destino.

Longitud del Datagrama = representa la longitud de octetos de este

Checksum = Es la suma de comprobacin de errores del mensaje

Payload = en este campo est el paquete RTP previamente analizado con la

El protocolo IPV4 est definido dentro de los estndares de la IETF

Este protocolo tiene dos funciones las cuales son direccionamiento y

CAPITULO 3 ESTUDIO DE TRFICO

Se cuenta con mdulos en cada punto ya sea de los Host o equipos

Utiliza cuatro mecanismos para prestar su servicio, los cuales son:

Suma de Control de Cabecera

El tipo de servicio se refiere a la calidad de servicio deseado, es un

Tiempo de vida: es el lmite de vida de un datagrama, es fijado por el

Opciones: dan funciones de control en casos especiales pero no tal

Suma de control de Cabecera se lo usa en la verificacin de que el

CAPITULO 3 ESTUDIO DE TRFICO

Funciones del Protocolo IPV4

En la clase A el Bit ms significativo es el 0, luego esta seguido por 7 bits

En la clase B los Bits ms significativos son 10 luego estn seguidos por 14

CAPITULO 3 ESTUDIO DE TRFICO

La clase D y E no son de uso comn en el primer caso los Bits ms

Fig. 3-3 Clases de direccionamiento IP

Esto es necesario cuando los paquetes se originan desde redes

permiten tamaos de paquetes grandes pero en el camino a su destino deben

En receptor se usa el campo de identificacin para garantizar que no se

Cuando se hace una fragmentacin se lo hace mnimo de 8 octetos para el

CAPITULO 3 ESTUDIO DE TRFICO

El campo de longitud total se marca con el tamao total del datagrama

Para re ensamblar el modulo en el host de destino toma todos los

Estructura de cabecera del Protocolo IPV4