servicios ip de calidad diferenciada para cliente...
Post on 09-Aug-2018
216 Views
Preview:
TRANSCRIPT
Servicios IP
de calidad diferenciada para cliente residencial y de negocio
Grupo 7 David Matellano Criado Ángel Pérez Villar Peter Trullenque Eriksson
Índice 1. Prólogo
2. Calidad de servicio
2.1. Introducción
2.2. ¿Qué es la calidad de servicio?
2.3. Modelo de las deficiencias
2.4. Aplicación a Ip
3. IntServ
3.1. ¿Qué es IntServ?
3.1.1. Tipos de servicios
4. DiffServ
4.1. Introducción
4.2. ¿Qué es DiffServ?
4.2.1. Calidad de Servicio
4.2.2. Red DiffServ
4.2.2.1.1. Requerimientos
4.2.2.1.2. Modelo
4.2.3. Tipos de servicio
4.3. RFCs Modelo DiffServ
5. VPN
5.1. Introducción
5.2. ¿Qué es VPN?
5.3. Funcionamiento de una VPN
6. Conclusiones
7. Referencias
Prólogo
¿Permite IP diferenciar tipos de clientes? Y de ser así, ¿es viable técnica y
económicamente?
En las siguientes páginas, se tratará de resolver esas dos preguntas clave, y todas
las que se surjan a su alrededor. Para ello, se partirá como punto de partida del concepto
general de Calidad de Servicio (QoS), que servirá como medida diferenciadora del tipo
de cliente y/o servicio.
Se observarán los dos principales métodos para ofrecer dicha diferenciación de
QoS, analizando sus pros y sus contras: reserva frente a priorización . Por un lado, se
mostrará la arquitectura IntServ, que utiliza el primer método, y por otro lado, la
arquitectura DiffServ, que se apoya sobre la priorización. ¿Por qué DiffServ es
considerado una alternativa superior a IntServ?
Por último, se hará mención del concepto de VPN (redes privadas virtuales),
como servicio aplicado a empresas sobre la arquitectura DiffServ.
Calidad de servicio
Introducción
En la actualidad, existen una serie de parámetros que formarán en el cliente una
opinión positiva de la empresa. Todos ellos se acumulan en lo que se ha dado nombre
de “calidad de servicio”. Que en una definición un tanto vaga, podría decirse que es
satisfacer sobradamente todas las necesidades y expectativas del cliente.
Por lo tanto, será necesario disponer de información adecuada sobre los clientes
que contenga aspectos relacionados con sus necesidades y con los atributos en los que
se fijan para determinar el nivel de calidad conseguido.
La calidad, y más concretamente la calidad del servicio, se está convirtiendo en
nuestros días en un requisito imprescindible para competir en las organizaciones
industriales y comerciales de todo el mundo, ya que las implicaciones que tiene en la
cuenta de resultados, tanto en el corto como en el largo plazo, son muy positivas para
las empresas envueltas en este tipo de procesos.
”De esta forma, la calidad del servicio se convierte en un elemento estratégico
que confiere una ventaja diferenciadora y perdurable en el tiempo a aquellas que tratan
de alcanzarla”. (RUIZ, 2002)
¿Qué es la calidad de servicio?
Tanto la investigación académica como la práctica empresarial vienen
sugiriendo, desde hace ya algún tiempo, que un elevado nivel de calidad de servicio
proporciona a las empresas considerables beneficios en cuento a cuota de mercado,
productividad, costes, motivación del personal, diferenciación respecto a la
competencia, lealtad y capacitación de nuevos clientes, por citar algunos de los más
importantes. Como resultado de esta evidencia, la gestión de la calidad de servicio se ha
convertido en una estrategia prioritaria y cada vez son más los que tratan de definirla,
medirla y mejorarla.
Sin embargo, realizar la definición y la medida no ha resultado una tarea tan
sencilla. Y sobre todo en el ámbito de lo servicios, ya que la calidad no es un concepto
del todo definido e independiente para cada tipo de servicio.
Debido a esto, encontramos un gran número de investigaciones con diferentes
posibles definiciones y modelos de QoS. Y en la que nos centraremos en esta pequeña
introducción del estudio es el denominado Modelo de las Deficiencias de Parasuraman,
Zeithaml y Berry.
Modelo de las Deficiencias
La calidad de servicio se define como una función de la discrepancia entre las
expectativas de los consumidores sobre el servicio que van a recibir y sus
percepciones sobre el servicio efectivamente prestado por la empresa.
Los autores sugieren que reducir o eliminar dicha diferencia, depende de cuatro
diferencias o discrepancias (Todas ellas englobadas en una quinta). A continuación se
analizarán las cinco diferencias (gaps) propuestos en su trabajo origen y sus
consecuencias:
GAP 1: Discrepancia entre las expectativas de los clientes y las percepciones que la
empresa tiene sobre esas expectativas.
Una de las principales razones por las que la calidad de servicio puede ser
percibida como deficiente es no saber con precisión que es lo que los clientes esperan.
Este gap es el único que traspasa la frontera que separa a los clientes de los proveedores
del servicio, y surge cuando las empresas de servicios no conocen con antelación qué
aspectos son indicativos de alta calidad para el cliente, cuales son imprescindibles para
satisfacer sus necesidades y qué niveles de prestación se requieren para ofrecer un
servicio de calidad.
Por lo tanto, apreciamos la importancia de realizar estudios de mercado para ver
qué es lo que realmente desean los clientes.
GAP 2: Discrepancia entre la percepción que los directivos tienen sobre las
expectativas de los clientes y las especificaciones de calidad.
Hay ocasiones en las que aún teniendo información suficiente y precisa sobre
qué es lo que los clientes esperan, las empresas de servicios no logran cubrir esas
expectativas. Ello puede ser debido a que las especificaciones de calidad de los servicios
no son consecuentes con las percepciones que se tienen acerca de las expectativas de los
clientes. Es decir, que las percepciones no se traducen en estándares orientados al
cliente.
Que se sepa lo que los consumidores quieren, pero no se convierta ese
conocimiento en directrices claras y concisas para la prestación de los servicios puede
deberse a varias razones: que los responsables de la fijación de estándares consideren
que las expectativas de los clientes son poco realistas y no razonables, difíciles por tanto
de satisfacer, que asuman que es demasiado complicado prever la demanda; que crean
que la variabilidad inherente a los servicios hace inviable la estandarización; que no hay
un proceso formal de establecimiento de objetivos o que se fijen los estándares
atendiendo a los intereses de la empresa y no de sus clientes.
GAP 3: Discrepancia entre las especificaciones de calidad y el servicio realmente
ofrecido.
Conocer las expectativas de los clientes y disponer de directrices que las reflejen
con exactitud no garantiza la prestación de un elevado nivel de calidad de servicio. Si la
empresa no facilita, incentiva y exige el cumplimiento de los estándares en el proceso
de producción y entrega de los servicios, la calidad de éstos puede verse dañada. Así
pues, para que las especificaciones de calidad sean efectivas han de estar respaldadas
por recursos adecuado (personas, sistemas y tecnología) y los empleados deben ser
evaluados y recompensados en función de su cumplimiento.
El origen de esta deficiencia se encuentra, entre otras en las siguientes causas:
especificaciones demasiado complicadas o rígidas, desajuste entre empleados y
funciones, ambigüedad en la definición de los papeles a desempeñar en la empresa,
especificaciones incoherentes con la cultura empresarial o empleados que no están de
acuerdo con ellas y se sienten atrapados entre los clientes y la empresa, lo que da lugar a
conflictos funcionales, inadecuados sistemas de supervisión control y recompensa,
tecnología inapropiada que dificulta que las actuaciones se realicen conforme a las
especificaciones, ausencia de sentimiento de trabajo en equipo o falta de sincronización
de la oferta y la demanda.
GAP 4: Discrepancia entre el servicio real y lo que se comunica a los clientes sobre
él.
Este gap significa que las promesas hechas a los clientes a través de la
comunicación de Marketing no son consecuentes con el servicio suministrado. La
información que los clientes reciben a través de la publicidad, el personal de ventas o
cualquier otro medio de comunicación puede elevar sus expectativas, con lo que
superarlas resultarás más difícil.
Finalmente, observamos como la existencia de una deficiencia de la calidad
percibida en los servicios puede estar originada por cualquiera de las otras discrepancias
o una combinación de ellas. Luego la clave para cerrar el último gap, la diferencia entre
las expectativas y percepciones de los consumidores, está en cerrar los restantes gaps
del modelo:
GAP 5 = función del (GAP 1, GAP 2, GAP 3, GAP 4)
.
Fig. 1: Modelo de deficiencias
Aplicación a IP
La calidad de servicio (QoS) es el rendimiento de extremo a extremo de los
servicios electrónicos tal como lo percibe el usuario final. Los parámetros de QoS son:
el retardo, la variación del retardo (jitter) y la pérdida de paquetes. Una red debe
garantizar un cierto nivel de calidad de servicio para un nivel de tráfico que sigue un
conjunto especificado de parámetros:
Ampliación Redes 4-9
Jitter
Retardomedio Datagramas considerados
perdidos por haberse entregado demasiado tarde
Retardomínimo
El tiempo mínimo de propagación
depende de las características físicas
de la red
Relación entre la probabilidad de llegada de los datagramas y los parámetros del SLA
Pro
babi
lidad
Tiempo
Fig. 2: Retardo, jitter y pérdida de paquetes
Hoy en día, existen dos tipos de tecnologías para ofrecer esa calidad:
• Reserva fija del canal en función del flujo de datos (IntServ).
• Dando diferentes prioridades a los flujos de datos (DiffServ).
Ampliación Redes 4-12
¿Reserva o Prioridad?
•Los paquetes han de ir marcados con la prioridad que les corresponde
•La garantía se basa en factores estadísticos, es menos segura que la reserva de recursos (puede haber overbooking)
•Los routers no necesitan conservar información de estado.
Prioridad
•Requiere mantener información de estado en todos los routers por lo que pasa la comunicación
•Se requiere un protocolo de señalización para efectuar la reserva en todo el trayecto
•Los paquetes no necesitan llevar ninguna marca que indique como han de ser tratados, la información la tienen los routers
•Da una garantía casi total
Reserva
InconvenientesVentajas
Fig. 3: Reserva o Prioridad
Modelo IntServ
¿Qué es IntServ?
Modelo de trabajo basado en un protocolo de reserva (RSVP, ReSerVation
Protocol) que permite la reserva de recursos a lo largo de los routers implicados en
la comunicación. Para ello, se debe especificar una QoS para la aplicación determinada
o para un flujo de datos particular, y mantenerla a lo largo de todos los routers mediante
el envío de solicitudes de QoS a todos los nodos de la red a lo largo de la trayectoria de
los datos.
Tipos de servicios
• Garantizado: Garantiza un caudal mínimo y un retardo máximo siendo a veces
imposible de implementar por limitaciones físicas, ya que cada router del trayecto
debe dar las garantías necesarias.
• Carga Controlada: Ofrece una calidad similar a la de una red de datagramas
poco cargada ofreciendo supuestamente un retardo bajo pero sin garantías.
• Best Effort: No ofrece ninguna garantía y se comporta de forma similar a si no
tuviéramos QoS.
Dependiendo del tipo de servicio los recursos se reparten de diferentes formas:
Ampliación Redes 4-23
Garantizado
Carga controlada
Best EffortC
auda
l →→ →→
Reparto de recursos en IntServ
Tiempo →→→→
Fig. 4: Reparto de recursos en IntServ
Pero el principal problema de IntServ fue la escalabilidad. Como debía guardar mucha
información de estado en cada router, esto hacía inviable usar RSVP en grandes redes,
por ejemplo en el ‘core’ de Internet.
Ampliación Redes 4-33
Problema de escalabilidad de RSVP
Estos routers han de mantener información sobre muchos flujos y por
tanto mucha información de estado
‘Core’ deInternet
Fig. 5: Problemas de escalabilidad de RSVP
Modelo DiffServ
Introducción
El diseño original de Internet contemplaba un servicio ‘best effort’, es decir sin
ninguna garantía de calidad de servicio. Con la proliferación, a partir de 1994
aproximadamente, de aplicaciones de videoconferencia y multimedia en tiempo real en
Internet, muy sensibles a situaciones de congestión, creció el interés de adaptar los
protocolos de Internet para ofrecer algún tipo de Calidad de Servicio.
Pero en realidad, ya existía “algo” de Calidad de Servicio desde el principio en
IPv4, pues en la cabecera del datagrama se encontraba, como luego comentaremos, el
campo denominado TOS (Type Of Service) de ocho bits de los cuales los tres primeros
representaban una prioridad (allí denominada precedencia) que permitía marcar los
datagramas según su importancia, marcado que permitía establecer en principio
políticas o prioridades en la transmisión de los datagramas por la red.
Aunque la prioridad representa una cierta calidad de servicio, por cuanto que
permite clasificar los datagramas en categorías, no es capaz en general de ofrecer una
garantía estricta, al estilo de la ofrecida por ATM, donde es posible reservar un caudal
determinado para un circuito, aplicación o flujo determinado, asignándole un circuito
virtual CBR, por ejemplo. Aunque un flujo concreto marque sus datagramas con
máxima prioridad no es posible, en general, garantizarle un caudal mínimo o un retardo
máximo ya que podría sufrir congestión debido a un caudal excesivo de datagramas de
esa prioridad producido por el tráfico agregado de otros flujos.
Al parecer la única forma de ofrecer una calidad de servicio garantizada es
realizando una reserva previa de capacidad en todo el trayecto, al estilo de los circuitos
ATM; para ello es preciso que cada router intermedio tenga conocimiento de la
existencia de dicho flujo. Esto supone pasar del modelo no orientado a conexión,
utilizado en Internet, al orientado a conexión. Hacia 1995 había una tendencia en
Internet a desarrollar ese modelo y fruto de esta filosofía es la denominada arquitectura
de Servicios Integrados o IntServ (de Integrated Services). El elemento más conocido y
representativo de la arquitectura IntServ es el protocolo RSVP del cual hemos hablado
anteriormente. Curiosamente a pesar del interés que el modelo IntServ suscitó entre la
comunidad Internet su uso no se ha difundido, ni entre los fabricantes que han sido
reacios a implementarlo en los equipos, ni entre los ISPs, que tampoco lo han
desarrollado en sus redes. Según los expertos el fracaso del modelo IntServ se debe a su
no escalabilidad, es decir, a que el costo de su implementación crece cuando menos,
linealmente con la complejidad de la red. El problema está en que, al ser RSVP un
protocolo orientado a conexión los routers han de mantener una información de estado
de todos los flujos activos que pasan por ellos. Esta información de estado puede ser
aceptable en los routers de la periferia, pero resulta inmanejable en los routers del ‘core’
de la red que han de soportar miles de conexiones activas.
Debido a que la arquitectura IntServ seguía sin resolver el problema de la
calidad de servicio en Internet hacia 1997 apareció un modelo alternativo denominado
Arquitectura de Servicios Diferenciados o DiffServ. La idea básica de DiffServ
consiste en que cada paquete lleva escrito un código que indica a que clase
pertenece; se supone que los routers saben el tratamiento que han de dar a cada
una de las clases posibles, por lo que no han de mantener ninguna información
sobre conexiones o flujos concretos; el número de clases posibles es limitado e
independiente del número de hosts o de flujos que pasan por los routers, por lo que la
arquitectura DiffServ es escalable. En realidad el modelo DiffServ ‘reinventó’ hasta
cierto punto el olvidado y denostado campo TOS de IPv4, que incluía entre otras cosas
el subcampo precedencia que ya hemos comentado.
A partir de aquí, nos adentraremos en contar minuciosamente el concepto de
DiffServ, desde todos sus puntos de vista.
¿Qué es DiffServ?
La arquitectura DiffServ, se basa en la división del tráfico en diferentes clases y,
en la asignación de prioridades a estos agregados. Otra manera más ruda de decirlo
sería que, básicamente, la información sobre calidad de servicio se escribe en los
datagramas, no en los routers. Ésta es la diferencia fundamental con IntServ y es, la
que permite implementar una calidad de servicio escalable a cualquier cantidad de
flujos.
Este modelo, utiliza diferente información de la cabecera de los paquetes(por
ejemplo, DSCP (DiffServ Code Point), para distinguir los paquetes y conocer el
tratamiento que debe recibir el tráfico en los nodos de la red DiffServ.
Calidad de Servicio
Los servicios diferenciados (DiffServ) proporcionan mecanismos de calidad de
servicio para reducir la carga en dispositivos de la red a través de un mapeo entre flujos
de tráfico y niveles de servicio. Los paquetes que pertenecen a una determinada clase se
marcan con un código específico (DSCP). Este código, es todo lo que necesitamos para
identificar una clase de tráfico. La diferenciación de servicios se logra mediante la
definición de comportamientos específicos para cada clase de tráfico entre dispositivos
de interconexión (PHB-Per Hop Behavior).
De esta manera, a través de DiffServ planteamos asignar prioridades a los
diferentes paquetes que son enviados a la red. Los nodos intermedios (routers) tendrán
que analizar estos paquetes y tratarlos según sus necesidades. Ésta es la razón principal
por la que DiffServ ofrece mejores características de escalabilidad que IntServ.
Cada paquete IP lleva un byte llamado octeto de Tipo de Servicio (TOS octet).
Es una característica poco utilizada de IP. En la nueva versión 6 de IP de 128 bits, hay
un byte equivalente llamado octeto de Clase de Servicio.
Fig. 6: Campo DS - campo TOS de IPv4
Fig. 7: Campo DS – Campo de Clase de Tráfico de IPv6.
La primera tarea del grupo de DiffServ fue re-especificar este byte. Este campo de 6
bits es conocido como el campo de los Servicios Diferenciados y es marcado con un
patrón específico de bits llamado código DS, usado para indicar cómo cada router debe
tratar al paquete. Para enfatizar el hecho de que ninguna información de sesión se
necesita guardar, este tratamiento es conocido como Per-Hop Behavior (PHB). El octeto
luce así:
Fig. 8: Aspecto del octeto TOS.
El campo de 6 bits contiene hasta 64 diferentes valores binarios. Los códigos
extra restantes dejan espacio para innovación y optimizaciones operacionales locales. El
marcado puede ocurrir en dos lugares:
• La fuente original de tráfico, servidor web, marca el tráfico. Esto
tiene la ventaja de que el clasificador puede tener conocimiento explícito de la
aplicación en uso y puede por consecuencia marcar paquetes de una manera
dependiente de la aplicación.
• Un router, como el primer router que el tráfico encuentra, clasifica y marca el
tráfico. Esto tiene la ventaja de que no se necesita ningún cambio a servidores, pero
requiere de alguna “inteligencia” extra en los routers.
Cuando un paquete entra en un router, la lógica de encaminamiento selecciona
en su puerto de salida el valor DSCP que es usado para conducir el paquete a una cola
específica o tratamiento específico en ese puerto. El PHB en particular, es configurado
por un mecanismo administrador de red, configurando la tabla de comportamiento de
QoS dentro del router. Los estándares PHB son hasta ahora los siguientes:
• Default behavior: el valor de DSCP es cero y el servicio esperado es
exactamente el servicio por defecto de la Internet de hoy (por ej. la congestión y
pérdida son completamente descontroladas).
• Class selector behavior: siete valores DSCP funcionan desde el 001000 al
111000 y son específicos para seleccionar hasta siete comportamientos, cada uno de
los cuales tiene una mayor probabilidad de un envío a tiempo que su predecesor.
• Expedited Forwarding behavior (EF): el valor recomendado es 101110. La
tasa de partida del tráfico EF debe ser igual o superior a una tasa configurable. EF
intenta permitir la creación de servicios en tiempo real con una tasa de throughput
configurable. El objetivo es que el flujo agregado vea siempre o casi siempre, la cola
vacía.
• Assured Forwarding (AF) behavior: Consiste en tres sub-comportamientos,
AF1, AF2, AF3. Cuando la red está congestionada, los paquetes marcados con el
DSCP para AF1 tienen la menor probabilidad de ser descartados por cualquier
router y los paquetes marcados para AF2 la más alta. En general, hay N clases
independientes con M niveles de descarte dentro de cada clase. Lo más común es
N= 4 y M= 3. A cada clase se le deben asignar una mínima cantidad de recursos,
pudiendo obtener más si es que hay exceso.
Una vez visto los puntos clave de marcado, otro punto clave es que un router puede
cambiar el valor del DSCP.
Fig. 9:Variación del DSCP en un router.
Y que, el cambio del campo DS estará sujeto a un contrato entre los clientes y el
proveedor, SLA (Service Level Agreement).
Red DiffServ
En la arquitectura definida por DiffServ, que podemos observar en la figura 1,
aparecen nodos extremos DS de entrada y salida, así como, DS internos. Este conjunto
de nodos definen el dominio DiffServ y presenta un tipo de políticas y grupos de
comportamiento por salto (PHB), que determinarán el tratamiento de los paquetes en la
red.
Fig. 10: Red DiffServ
Se verá a continuación las diferentes funciones que deben realizar los nodos DS:
• Nodos extremos DS: Será necesario realizar diferentes funciones como el
acondicionamiento de tráfico entre los dominios DiffServ interconectados. De esta
manera, debe clasificar y establecer las condiciones de ingreso de los flujos de
tráfico en función de: dirección IP y puerto, tanto origen como destino, protocolo de
transporte y DSCP, este clasificador se conoce como MF (Multi-Field Classifier).
Una vez que los paquetes han sido marcados adecuadamente, los nodos internos
deberán seleccionar el PHB definido para cada flujo de datos.
Los nodos DS de entrada serán responsables de asegurar que el tráfico de
entrada cumple los requisitos de algún TCA (Traffic Conditioning Agreement), que
es una derivado del SLA, entre los dominios interconectados. Por otro lado, los
nodos DS de salida deberán realizar funciones de acondicionamiento de tráfico o TC
(Traffic Conformation) sobre el tráfico transferido al otro dominio DS conectado.
• Nodos internos DS: Podrá realizar limitadas funciones de TC, tales como
remarcado de DSCP. Los nodos DS internos sólo de conectan a nodos internos o a
nodos externos de su propio dominio. A diferencia de los nodos externos para la
selección del PHB sólo se tendrá en cuenta el campo DSCP, conocido como
clasificador BA (Behavior Aggregate Classifier).
Requerimientos
La historia de Internet ha sido de un completo crecimiento en cuanto al número
de hosts, la gran variedad de aplicaciones y la capacidad de la infraestructura de la red.
Por lo tanto, una arquitectura escalable para servicios diferenciados debe permitir
acomodar este continuo crecimiento.
Los siguientes requerimientos fueron identificados y ubicados en esta arquitectura:
• Debe acomodar una amplia variedad de servicios y proveer políticas,
extendiendo una red punta a punta o una red particular.
• Debe permitir el desacoplamiento del servicio de la aplicación particular en uso.
• Debe trabajar con aplicaciones existentes sin la necesidad de mas cambios en
interfaces de aplicaciones programables.
• Debe desacoplar las funciones de condicionamiento de tráfico y
aprovisionamiento de servicios de comportamientos de envío implementados en
los nodos del núcleo de la red.
• No debe depender de la aplicación de señalización salto a salto.
• Debe requerir solo una pequeña cantidad de comportamientos de envío, cuya
complejidad de implementación no domine el costo de un dispositivo de red.
• Debe utilizar solo estado de clasificación de agregados dentro del núcleo de la
red.
• Debe permitir interoperabilidad razonable con nodos de red no DS capaces.
• Debe permitir implementaciones de clasificación de paquetes simples en nodos
del núcleo de la red.
• Debe evitar estados por microflujos o por clientes dentro de los nodos del
núcleo.
• Debe acomodar despliegue incremental.
Modelo
Las redes IP están compuestas de nubes, regiones de relativa homogeneidad en
términos del control administrativo, tecnología, ancho de banda, etc. Determinando
dónde terminan las nubes y las fronteras, nosotros determinamos dónde administrar los
recursos y dónde el control es aplicado, para asegurarse que la política se lleva a cabo.
Dentro de una nube, es posible sacar ventaja de la uniformidad dentro de su
frontera, al agregar flujos de tráfico individuales en un número limitado de agregados de
tráfico, donde cada uno tendrá un distinto trato de envío. Por lo tanto, el tráfico entrante
a la red es clasificado y posiblemente condicionado en los bordes de la red, y asignado a
diferentes “behavior aggregates” (BA). Dentro de una nube, todo lo que es importante
sobre un paquete para determinar el trato de envío es saber a qué agregado pertenece,
siendo posible confiar en una marca puesta en el paquete para indicar su agregado.
La forma en que una decisión de política específica sobre QoS es implementada,
es por medio de la clasificación, monitoreo, marcado, política y otros
condicionamientos del tráfico del paquete en las fronteras de las nubes, luego de los
cuales los paquetes reciben un trato uniforme dentro de las nubes. Casi todo el trabajo
es confinado al borde de las nubes. Las reglas para alojar recursos deben no ser visibles
fuera de la nube, siéndolo, solamente los agregados de comportamiento.
DiffServ utiliza el tráfico agregado como su unidad fundamental de tráfico, más
que como una corriente. Un campo de 6 bits en cada paquete identifica su agregado de
tráfico (BA) en el centro de la red y por lo tanto, el trato de envío que cada paquete en el
agregado va a recibir, sin importar a que microflujo éste pertenezca. Cada BA es
identificado por un único código DS. Dentro del núcleo de la red, los paquetes son
enviados de acuerdo al comportamiento por salto asociado al código DS.
En el borde de la red, más estado de paquetes debe ser guardado al marcar más campos
de paquetes; por lo tanto, los agregados del interior podrían estar hechos de paquetes de
varios clientes, y ser condicionados y politizados diferente en el borde, pero con la
misma expectativa de trato de envío una vez pasado el borde.
Los routers dentro del dominio van a ser configurados para tratar a cada
agregado de tráfico en forma diferente: en un dominio que reconoce a N agregados, los
routers serán cada uno capaz de tener N comportamientos de envío diferente, uno
apropiado para cada agregado.
Tipos de servicios
• Servicio ‘Expedited Forwarding’ o ‘Premium’ : Este servicio es el de mayor
calidad. Se supone que debe ofrecer un servicio equivalente a una línea dedicada
virtual, o a un circuito ATM CBR o VBR-rt. Debe garantizar un caudal mínimo, una
tasa máxima de pérdida de paquetes, un retardo medio máximo y un jitter máximo.
El valor del subcampo DSCP relacionado con este servicio es ‘101110’.
• Servicio ‘Assured Forwarding’: Este servicio asegura un trato preferente, pero
no garantiza caudales, retardos, etc. Se definen cuatro clases posibles pudiéndose
asignar a cada clase una cantidad de recursos en los routers (ancho de banda,
espacio en buffers, etc.). La clase se indica en los tres primeros bits del DSCP. Para
cada clase se definen tres categorías de descarte de paquetes (probabilidad alta,
media y baja) que se especifican en los dos bits siguientes (cuarto y quinto). Existen
por tanto 12 valores de DSCP diferentes asociados con este tipo de servicio, que
son:
Precedencia de
descarte
Clase Baja Medi
a
Alta
4 1000
1
10010 10011
3 0110
1
01110 01111
2 0100
1
01010 01011
1 0010
1
00110 00111
Fig. 11: ‘CodePoints’ utilizados en el servicio Assured Forwarding.
En el servicio Assured Forwarding el proveedor puede aplicar traffic policing
(vigilancia de tráfico) al usuario, y si el usuario excede lo pactado el proveedor puede
descartar datagramas, o bien aumentar la precedencia de descarte.
• Servicio Best Effort: este servicio se caracteriza por tener a cero los tres
primeros bits del DSCP. En este caso los dos bits restantes pueden utilizarse para
marcar una prioridad, dentro del grupo ‘best effort’. En este servicio no se ofrece
ningún tipo de garantías.
Al igual que en IntServ, dependiendo del tipo de servicio, los recursos se reparten de
diferente manera:
Ampliación Redes 4-50
Expedited Forwarding o Premium
Assured Forwarding
Best Effort sin prioridad
Cau
dal →→ →→
Reparto de recursos en DiffServ
Tiempo →→→→
Best Effort con prioridad
Fig. 12: Reparto de recursos en DiffServ.
Algunos ISPs (proveedores de servicios Internet) ofrecen servicios denominados
‘olímpicos’ con categorías denominadas oro, plata y normal (o tiempo-real, negocios y
normal). Generalmente estos servicios se basan en las diversas clases del servicio
Assured Forwarding.
El campo DS es una incorporación reciente en la cabecera IP. Anteriormente
existía en su lugar un campo denominado TOS o ‘Tipo de Servicio’ que tenía la
siguiente estructura:
Subcampo Longitud
(bits)
Precedencia 3
Flags D, T, R, C 4
Reservado 1
Fig. 13: Estructura del campo ‘Tipo de servicio’.
El subcampo ‘Precedencia’ permitía especificar una prioridad entre 0 y 7 para el
datagrama (7 máxima prioridad). Este campo es en cierto modo el antecesor del campo
DS. A continuación se encontraba un subcampo compuesto por cuatro bits que actuaban
como indicadores o ‘flags’ mediante los cuales el usuario podía indicar sus preferencias
respecto a la ruta que seguiría el datagrama. Los flags, denominados D, T, R y C
permitían indicar si se prefería una ruta con servicio de bajo retardo (D=Delay), elevado
rendimiento (T=Throughput), elevada fiabilidad (R=Reliability) o bajo costo (C=Cost).
El campo TOS ha sido muy impopular: el subcampo precedencia se ha implementado
muy raramente en los routers. En cuanto a los flags D,T,R,C prácticamente no se han
utilizado y su inclusión en la cabecera IP ha sido muy criticada. Estos problemas
facilitaron evidentemente la ‘transformación del campo TOS en el DS, aunque existen
todavía routers en Internet que interpretan este campo con su antiguo significado de
campo TOS. Dado que DiffServ casi siempre utiliza solo los tres primeros bits del
DSCP para marcar los paquetes, y que los servicios de mas prioridad, como es el caso
del Expedited Forwarding, se asocian con los valores más altos de esos tres bits, en la
práctica hay bastante compatibilidad entre el nuevo campo DSCP del byte DS y el
antiguo campo Precedencia del byte TOS, como puede verse en la tabla siguiente:
Valor Campo
Precedencia
Servicio DiffServ
correspondiente
7 Reservado
6 Reservado
5 Expedited Forwarding
4 Assured Forwarding clase 4
3 Assured Forwarding clase 3
2 Assured Forwarding clase 2
1 Assured Forwarding clase 1
0 Best Effort
Fig. 14: Correspondencia del campo precedencia con los servicios DiffServ.
Evidentemente esta compatibilidad no es accidental. Tradicionalmente el campo
Precedencia no hacía uso de los dos niveles de prioridad más altos, que quedaban
reservados para mensajes de gestión de la red, como datagramas del protocolo de
routing. En DiffServ se han reservado también los dos valores más altos de los tres
primeros bits con lo que se mantiene la compatibilidad con el campo precedencia.
RFCs Modelo DiffServ
• RFC 2430 (10/1998): A Provider Architecture for DiffServ and Traffic Eng.
• RFC 2474 (12/1998): Definition of the DS field in the IPv4 and IPv6 Headers
• RFC 2475 (12/1998): An Architecture for Differentiated Service
• RFC 2597 (6/1999): Servicio Expedited Forwarding
• RFC 2598 (6/1999): Servicio Assured Forwarding
• RFC 2638 (7/1999): A Two-bit DiffServ Architecture for the Internet
• RFC 2963 (10/2000): A Rate Adaptive Shaper for Differentiated Services
• RFC 2983 (10/2000) Differentiated Services and Tunnels
• RFC 3086 (4/2001): Def. of DiffServ Per Domain Behaviors & Rules for Spec.
• RFC 3270 (5/2002): MPLS Support of DiffServ
• RFC 3287 (7/2002): Remote Monitoring MIB Extensions for DiffServ
• RFC 3289 (5/2002): Management Information Base for the DiffServ Architect.
VPN
Introducción
Hace unos años no era tan necesario conectarse a Internet por motivos de
trabajo. Conforme ha ido pasado el tiempo las empresas han visto la necesidad de que
las redes de área local superen la barrera de lo local permitiendo la conectividad de su
personal y oficinas en otros edificios, ciudades, comunidades autónomas e incluso
países.
Por otro lado se encontraban las grandes inversiones que eran necesarias realizar
tanto en hardware como en software y por supuesto, en servicios de telecomunicaciones
que permitiera crear estas redes de servicio.
Afortunadamente con la aparición de Internet, las empresas, centros de
formación, organizaciones de todo tipo e incluso usuarios particulares tienen la
posibilidad de crear una Red privada virtual (VPN) que permita, mediante una
moderada inversión económica y utilizando Internet, la conexión entre diferentes
ubicaciones salvando la distancia entre ellas.
Las redes virtuales privadas utilizan protocolos especiales de seguridad que
permiten obtener acceso a servicios de carácter privado, únicamente a personal
autorizado, de una empresas, centros de formación, organizaciones, etc.; cuando un
usuario se conecta vía Internet, la configuración de la red privada virtual le permite
conectarse a la red privada del organismo con el que colabora y acceder a los recursos
disponibles de la misma como si estuviera tranquilamente sentado en su oficina.
VPN es, por tanto, una aplicación con una clara preferencia al cliente
“empresario” sobre el cliente “residencial”. De esta manera, el desarrollo de DiffServ
podría presentar un especial interés de cara a la creación de VPNs sobre una red IP.
¿Qué es una VPN?
Realmente una VPN no es más que una estructura de red corporativa implantada
sobre una red de recursos de carácter público, pero que utiliza el mismo sistema de
gestión y las mismas políticas de acceso que se usan en las redes privadas, al fin y al
cabo, no es más que la creación en una red pública de un entorno de carácter
confidencial y privado que permitirá trabajar al usuario como si estuviera en su misma
red local.
Funcionamiento de una VPN
Como hemos indicado en un apartado anterior, desde el punto de vista del
usuario que se conecta a ella, el funcionamiento de una VPN es similar al de cualquier
red normal, aunque realmente para que el comportamiento se perciba como el mismo
hay un gran número de elementos y factores que hacen esto posible.
La comunicación entre los dos extremos de la red privada a través de la red
pública se hace estableciendo túneles virtuales entre esos dos puntos y usando sistemas
de encriptación y autentificación que aseguren la confidencialidad e integridad de los
datos transmitidos a través de esa red pública. Debido al uso de estas redes públicas,
generalmente Internet, es necesario prestar especial atención a las cuestiones de
seguridad para evitar accesos no deseados.
La tecnología de túneles (Tunneling) es un modo de envío de datos en el que se
encapsula un tipo de paquetes de datos dentro del paquete de datos propio de algún
protocolo de comunicaciones, y al llegar a su destino, el paquete original es
desempaquetado volviendo así a su estado original.
En el traslado a través de Internet, los paquetes viajan encriptados, por este
motivo, las técnicas de autenticación son esenciales para el correcto funcionamiento de
las VPNs, ya que se aseguran a emisor y receptor que están intercambiando información
con el usuario o dispositivo correcto.
La autenticación en redes virtuales es similar al sistema de inicio de sesión a
través de usuario y contraseña, pero tienes unas necesidades mayores de aseguramiento
de validación de identidades.
La mayoría de los sistemas de autenticación usados en VPN están basados en
sistema de claves compartidas.
La autenticación se realiza normalmente al inicio de una sesión, y luego,
aleatoriamente, durante el transcurso de la sesión, para asegurar que no haya algún
tercer participante que se haya podido entrometer en la conversación.
Todas las VPNs usan algún tipo de tecnología de encriptación, que empaqueta
los datos en un paquete seguro para su envío por la red pública.
La encriptación hay que considerarla tan esencial como la autenticación, ya que
permite proteger los datos transportados de poder ser vistos y entendidos en el viaje de
un extremo a otro de la conexión.
Existen dos tipos de técnicas de encriptación que se usan en las VPN:
Encriptación de clave secreta, o privada, y Encriptación de clave pública.
En la encriptación con clave secreta se utiliza una contraseña secreta conocida
por todos los participantes que van a hacer uso de la información encriptada. La
contraseña se utiliza tanto para encriptar como para desencriptar la información. Este
tipo de sistema tiene el problema que, al ser compartida por todos los participantes y
debe mantenerse secreta, al ser revelada, tiene que ser cambiada y distribuida a los
participantes, lo que puede crear problemas de seguridad.
La encriptación de clave pública implica la utilización de dos claves, una
pública y una secreta. La primera es enviada a los demás participantes. Al encriptar, se
usa la clave privada propia y la clave pública del otro participante de la conversación.
Al recibir la información, ésta es desencriptada usando su propia clave privada y la
pública del generador de la información. La gran desventaja de este tipo de encriptación
es que resulta ser más lenta que la de clave secreta.
En las redes virtuales, la encriptación debe ser realizada en tiempo real, de esta
manera, los flujos de información encriptada a través de una red lo son utilizando
encriptación de clave secreta con claves que son válidas únicamente para la sesión
usada en ese momento.
Conclusiones
En la actualidad, la red de datos tiene que soportar un tráfico mayor que aumenta
día a día de forma alarmante: servicios de descarga masiva, emisión de video, telefonía
sobre IP, ...
Todo esto, hace que la red este cada día más colapsada haciendo muy complicado
mantener la calidad de servicio. ¿Qué podemos hacer al respecto?
A simple vista, tenemos dos posibles grandes soluciones:
• Aumentar la red de transporte según sea necesario, abaratando lo máximo
posible los sistemas de comunicación y transporte.
• Gestionar de forma diferente los recursos disponibles, teniendo en cuenta su
origen, tipo de servicio, prioridad…
Si optamos por la primera opción nos dirigimos hacia una red en la que no
aprovechamos al 100% los recursos disponibles. Y, sin embargo, con la segunda
opción, tendemos una red que no trata de forma similar a los usuarios. ¿Cuál es la mejor
opción?
Desde un punto de vista técnico, se llegará a un límite en el cual no resultará posible
aumentar más las redes. Así mismo, desde un punto de vista económico, antes de llegar
a dicha limitación física, dejará de ser rentable. Este factor será el punto de inflexión a
partir del cual, nos veamos obligados a gestionar de manera diferenciada las redes.
En este cauce, el modelo DiffServ tomará el control de las redes, siendo la alternativa a
la diferenciación de clientes residenciales o clientes de negocio. El servicio Best-Effort,
actualmente usado en las redes, será sustituido por los servicios EF y AF. El primero de
ellos, estará destinado a clientes preferentes de tipo empresa, debido a las motivaciones
económicas principalmente, asegurándoles un caudal y un retardo óptimos. El segundo
servicio, es decir, AF, estará destinado por su parte, al usuario privado, asegurando
cierta QoS (sin las prestaciones del anterior servicio) y distinguiendo a su vez, varias
clases dentro de sí.
Sin embargo, desde un punto de vista social, nos enfrentamos a la tradicional
separación de pobres y ricos. Es lógico pensar, que los clientes de negocio, al tener
mayor inyección económica, podrán acceder a servicios exclusivos que para la mayoría
de la sociedad, resulta impensable. En este punto, nos encontramos con el sentimiento
moral de justicia.
Desde un punto de vista objetivo, en el futuro se tendrá que optar por DiffServ.
Pero, ¿a qué costo moral? Desde nuestro punto de vista, no es necesario hacer la
distinción de pobres y ricos nombrada anteriormente, si no por servicios ofrecidos.
Referencias
Calidad de servicio
- http://www.monografias.com/trabajos12/calser/calser.shtml
- http://cica.es/aliens/jaescadiz/Archivos%20pdf/Archivos%20pdf%20tc/011tc.pdf
- http://es.wikipedia.org/wiki/Calidad_de_Servicio
- http://www2.ing.puc.cl/~iee3542/ “Apuntes referidos a calidad de servicio”
- http://www.it.uc3m.es/cgarcia/articulos/cita2002_diffserv.pdf “DiffServ como
solución a la provisión de QoS en Internet” por Jorge Escribano Salazar, Carlos García
García, Celia Seldas Alarcóny José Ignacio Moreno Novella
IntServ
- http://www2.ing.puc.cl/~iee3542/ “Apuntes referidos a calidad de servicio”
- http://www.it.uc3m.es/cgarcia/articulos/cita2002_diffserv.pdf “DiffServ como
solución a la provisión de QoS en Internet” por Jorge Escribano Salazar, Carlos García
García, Celia Seldas Alarcóny José Ignacio Moreno Novella
DiffServ
- http://www2.ing.puc.cl/~iee3542/ “Apuntes referidos a calidad de servicio”
- http://jogiguz.webs.upv.es/papers/JTRedIris03.pdf “Red Experimental DiffServ
Utilizando Router-PCs con Sistema Operativo Linux” por José Manuel Giménez
Guzmán y Jorge Martínez Bauset
- http://docs.sun.com/app/docs/doc/820-2981/ipqos-intro-54?l=es&a=view
- http://www.it.uc3m.es/cgarcia/articulos/cita2002_diffserv.pdf “DiffServ como
solución a la provisión de QoS en Internet” por Jorge Escribano Salazar, Carlos García
García, Celia Seldas Alarcóny José Ignacio Moreno Novella
- “Nuevas soluciones en internet: IntServ y DiffServ” por Cláudia Jacy Barenco Abbas
VPN
- http://www.it.uc3m.es/cgarcia/articulos/cita2002_diffserv.pdf “DiffServ como
solución a la provisión de QoS en Internet” por Jorge Escribano Salazar, Carlos García
García, Celia Seldas Alarcóny José Ignacio Moreno Novella
- http://en.wikipedia.org/wiki/Vpn
- http://www.configurarequipos.com/doc499.html
top related