2 2-diff serv-intserv

1. Arquitecturas de Calidad de Servicio:
DiServ e IntServ
Planicacion y gestion de redes de ordenadores
Departamento de Sistemas Telematicos y Computacion (GSyC)
Octubre de 2012
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 1

2. Transparencias adaptadas del material de los libros
que aparecen referenciados al nal del chero
c2012 Grupo de Sistemas y Comunicaciones.
Algunos derechos reservados.
Este trabajo se distribuye bajo la licencia
Creative Commons Attribution Share-Alike
disponible en http://creativecommons.org/licenses/by-sa/3.0/es
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 2

3. Contenidos
1
Introduccion
2
IETF Dierentiated Services
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 3

4. Introduccion
Contenidos
1
Introduccion
2
IETF Dierentiated Services
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 4

5. Introduccion
DiServ vs IntServ
DiServ: Los paquetes se marcan a la entrada de la red
DiServ, segun diferentes categoras o clases. Entre diferentes
clases se establecen diferentes parametros de QoS. En una
misma clase se agregan diferentes ujos que recibiran el
mismo tratamiento de QoS.
IntServ (RSVP): antes de utilizar la red es necesario solicitar
una reserva de recursos a lo largo de todo el camino por el
que circularan los paquetes, desde el origen al destino. Se
obtiene una garanta de que se va a conseguir cierta QoS.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 5

6. IETF Dierentiated Services
Contenidos
1
Introduccion
2
IETF Dierentiated Services
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 6

7. IETF Dierentiated Services
IETF Dierentiated Services (DiServ)
Buscamos ofrecer clases de servicio cualitativas con un
comportamiento particularizado para cada clase, como si cada
una tuviese un medio de transmision en exclusiva
Escalabilidad:
relativamente complejas en losroutersde frontera
terminales
La
como la red telefonica requiere manterner informacion de
estado en el router para cada ujo
No escala si hay muchos ujos
La
dene clases de servicios concretas sino que ofrece
componentes funcionales que permiten construir clases de
servicio
IETF: Internet Engineering Task Force
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 7

8. IETF Dierentiated Services
Arquitectura de DiServ
Router frontera
Router del nucleo de la red
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 8

9. IETF Dierentiated ServicesRouter Frontera
Contenidos
1
Introduccion
2
IETF Dierentiated Services
Router Frontera
Router del Nucleo
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 9

10. IETF Dierentiated ServicesRouter Frontera
Router frontera (Edge Router)
Realiza
(shaping/policing)
Se usa tambien untoken bucketcon granularidad de
En este caso eltoken bucketse usa para adecuar el traco
inyectado a lo contratado
Marca
si respetan o no lo acordado (lmites de tasa promedio, de
pico,...)
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 10

11. IETF Dierentiated ServicesRouter Frontera
Arquitectura de DiServ en Router Frontera
1
En primer lugar los paquetes que llegan al
routerde frontera se:
El clasicador selecciona los paquetes
basandose en los valores de uno o mas
campos de la cabecera del paquete
(direccion origen, destino, puerto origen,
destino, identicador de protocolo)
2
A continuacion se
categoras o clases.
3
Puede ser deseable limitar la tasa de
inyeccion de traco para alguna de las clases
de servicio:
El usuario
de pico, tasa promedio, tama~no de rafaga)
usando la abstraccion de la cubeta
El traco es medido y acondicionado (si no
respeta el perl de traco declarado se
descarta, o se marca comoout-prole)r
b
marking
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 11

12. IETF Dierentiated ServicesRouter Frontera
Marcado del traco DiServ en la cabecera IPv4
Los paquetes se marcan en el campo de 8 bits Type of Service
(ToS) de IPv4!"#$%&'((
)*'+%,-.(
/01"/"#0((
23*(."($"#!%/%*( )*'+%,-.(,*,0)(.0,0+#040(
%."'25/0.*#(.")(.0,0+#040(#"$(67(87( !"#$%&."(9#0+4"',0/%&'(
::;((
<2"43*(."(!%.0=(
3#*,*/*)*( '($')#*+(."()0(/01"/"#0(
.%#"//%&'(>?(*#%+"'(
.%#"//%&'(>?(."$2'*(
*3/%*'"$((
6@:AB(>?(
Cabecera IP
Datos IP
0 4 8 16 31
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 12

13. IETF Dierentiated ServicesRouter Frontera
Marcado del traco DiServ en la cabecera IPv6
Los paquetes se marcan en el campo de 8 bits clase de traco
de IPv6Ver$
Clase$de$
tráfico$
E0queta$
de$flujo$
Longitud$
de$datos$
Siguiente$
cabecera$
Límite$de$
saltos$
Dirección$Des0no$(128$bits)$
64$bits$
Dirección$Origen$(128$bits)$
4$$$$$$$$$$8$$$$$$$$$$$$$$$$$$$$$20$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$16$$$$$$$$$$$$$$$8$$$$$$$$$$$$$$$$$8$
Datos$
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 13

14. IETF Dierentiated ServicesRouter Frontera
Marcado del traco DiServ: campo DSCP
Se usan 6 bits para identicarDierentiated Service Code
Point (DSCP)que determinan el comportamiento por salto
(PHB, Per-Hop Behavior) que recibira el paquete en los
routersde la red DiServ.
Quedan los 2 bits menos signicativos del campo ToS que no
se usan para DiServ, sino para la noticacion de congestion
(Explicit Congestion Notication, ECN). ECN es utilizado
conjuntamente por los extremos de una conexion TCP y los
routers intermedios que usan la disciplina de cola RED,
Random Early Detection.DS5$DS4$DS3$DS2$DS1$DS0$ECN$ECN$
DSCP%(6%bits)%
Prio:%%
DS5$DS4$DS3$
7$ 1$ 1$1$
6$ 1$ 1$0$
5$ 1$ 0$1$Express$Forwarding$(EF)$
4$ 1$ 0$0$Assured$Forwarding$(AF),$clase$4$
3$ 0$ 1$1$Assured$Forwarding$(AF),$clase$3$
2$ 0$ 1$0$Assured$Forwarding$(AF),$clase$2$
1$ 0$ 0$1$Assured$Forwarding$(AF),$clase$1$
0$ 0$ 0$0$Best$Effort$(BE)$
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 14

15. IETF Dierentiated ServicesRouter del Nucleo
Contenidos
1
Introduccion
2
IETF Dierentiated Services
Router Frontera
Router del Nucleo
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 15

16. IETF Dierentiated ServicesRouter del Nucleo
Router del Nucleo de la red
Realiza funciones con una granularidad de
funcion de la marca que trae cada paquete y no en funcion de
cada ujo (origen y destino). Todos los paquetes de cada clase
son tratados igual.
Se encola y se planica el envo de cada paquete basandose en
las routersde frontera
Se da preferencia a los paquetes marcados como
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 16

17. IETF Dierentiated Services Router del Nucleo
Arquitectura de DiServ en Router del Nucleo de la red
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012 DiServ e IntServ 17

18. IETF Integrated services
Introduccion
Principio 4 de la QoS:
Si los recursos necesarios no siempre van a estar disponibles y es
necesario garantizar la calidad de servicio, se necesita un proceso
de
de QoS y, o bien se les admita en la red, o se les rechace en
funcion de si la red puede o no proporcionar la QoS requeridaR1
R2
1.5 Mbps link
1 Mbps
phone
1 Mbps
phone
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 25

19. IETF Integrated services
Integrated Services (IntServ)
Trabajo del IETF entre 1995 y 1997
Desarrollaron especicaciones para un conjunto de
servicio
clases de aplicaciones.
Para ofrecer QoS, IntServ se basa en un modelo de reserva de
recursos por ujo en todo el trayecto que siguen los paquetes
de dicho ujo.
Un ujo queda identicado por la direccion IP origen, la
direccion IP destino, el protocolo de nivel de transporte y
opcionalmente el puerto destino.
La aplicacion es responsable de gestionar la reserva de
recursos en la red.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 26

20. IETF Integrated services
IntServ: Clase de servicioGuaranteed service
SERVICIO GARANTIZADO
Para aplicaciones
nunca se descarte y no llegue tarde
La red debe garantizar que el maximo retardo que cualquier
paquete puede experimentar tiene un valor especicado
La aplicacion puede entonces planicar cuando comenzar a
reproducir despues de empezar a recibir datos de un ujo
multimedia que va siendo almacenado localmente antes de
comenzar la reproduccion
Analogo a EF (expedited forwarding) de DiServ.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 27

21. IETF Integrated services
IntServ: Clase de servicioControlled load
SERVICIO DE CARGA CONTROLADA
Para aplicaciones
Estas aplicaciones funcionan bien en redes poco
congestionadas, reajustando cuantobueringrealizan antes de
comenzar a reproducir adaptativamente segun los retardos
observados dinamicamente
Emula una red poco cargada aunque haya congestion.
>Como?
Con WFQ se aisla el traco y con control de admision se limita
la cantidad de traco de tipocontrolled load
Analogo a AF (assured forwarding) de DiServ.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 28

22. IETF Integrated services
Mecanismos de IntServ
1
Flowspec: Se necesita un servicio para comunicar a la red el
tipo de servicio requerido por cada aplicacion
Cualitativamente (ej. \quierocontrolled load") o
cuantitativamente (\quiero retardo maximo de 100ms")
2
Control de admision: la red tiene que decidir si puede o no
proporcionar el servicio requerido
3
Protocolo de reserva de recursos (RSVP): las aplicaciones que
generan el traco y los elementos de la red tienen que
intercambiar informacion como peticiones de servicio,
owspecsy el resultado de las decisiones de control de
admision (llamado se~nalizacion en redes de conmutacion de
circuitos)
4
Disciplinas de planicacion: los routerstienen que cumplir los
requisitos especicados en losowspec
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 29

23. IETF Integrated services
Flowspecs
Dos partes diferenciadas:
TSpec (Trac Specication): describe las caractersticas del
traco del ujo que se va a enviar usando la abstraccion de la
cubeta con chas (token bucket)
RSpec (Request Specication): servicio que se requiere de la
red. Ej. \Controlled load service". Para \Guaranteed service"
hay que especicar el lmite del retardo.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 30

24. IETF Integrated services
Ejemplo deTSpec
Un
especicacion con la abstraccion de la cubeta con chas:
r= 1MBps;b= 1Byte
Un
lo hace transmitiendo:
0'5 MBps durante 2 segundos
2 MBps durante 1 segundo
rde la cubeta dene la media a largo plazo, luegortambien es 1MBps
para este ujo, pero para caracterizar el ujo B necesitamos un tama~no
bde cubeta de al menos 1MB:
durante los 2 primeros segundos transmite a 0'5MBps, ahorrando 1MB,
que sumados a 1MB del tama~no de la cubeta le permite enviar 2MBps
en el tercer segundo
Un mismo ujo se puede describir con diferentes combinaciones r,b de
cubetas. Ejemplo: el ujo A tambien se puede describir como el ujo
B, pero se trata de usar el que describe de manera mas ajustada a la
realidad
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 31

25. IETF Integrated services
Ejemplo deTSpec BW
Time
1
2
1 2 3
Flow A
Flow B
Flow A: r = 1 MBps, B=1 byte
Flow B: r = 1 MBps, B=1MB
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 32

26. IETF Integrated services
Control de admision
Cuando un nuevo ujo quiere recibir un nivel de servicio el
control de admision decide si la TSpec y la RSpec se pueden
satisfacer en funcion de los recursos actuales sin perjudiar al
resto de ujos
La parte difcil es decidir si aceptar o no un ujo.
Paraguaranteed servicees mas difcil salvo que se disponga
de WFQ en cadarouter
Paracontrolled load servicese determina en funcion de
heursticos: \la ultima vez que permit a un ujo con esta
TSpec entrar en esta clase los retardos de la clase de traco
subieron demasiado as que lo rechazo"
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 33

27. IETF Integrated services
Protocolo de reserva de recursos RSVP
RSVP: Resource Reservation Protocol
RSVP es robusto ante fallos deencaminadoreso enlaces
gracias a que usa: la informacion que almacenan los
routers se borra si no se actualiza periodicamente
Soporta traco multidifusion (multicast). Origen en
aplicaciones de IP multicast como vat y vic
RSVP es: cada receptor tiene unos
requisitos distintos para una misma transmision
Soft state + orientado al receptor permite exibilidad al
receptor: es facil mandar nueva peticion con diferente RSpec.
La antigua se borra sola pasado un tiempo.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 34

28. IETF Integrated services
Funcionamiento de RSVP
Antes de que el receptor pueda hacer una reserva:
El receptor tiene queconocer el tipo de traco del emisor
para poder hacer entonces una reserva de recursos adecuada:
necesita conocer la TSpec del emisor
El receptor necesitaconocer la rutaque recorren los
paquetes desde el emisor al receptor para instalar en los
routersde ese camino las reservas.
El camino de ida no tiene por que ser igual al camino de vuelta.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 35

29. IETF Integrated services
Funcionamiento de RSVP
1
El emisor manda un mensaje
con la TSpec.
2
Cada encaminador por el que pasa el mensaje PATH se apunta el
camino inverso para poder hacer llegar luego mensajes de reserva de
los receptores al emisor.
RSVP no es un protocolo de encaminamiento, no calcula rutas. Los
paquetes siguen el camino que indica la tabla de encaminamiento.
3
Tras recibir el mensaje PATH el receptor enva de vuelta un mensaje
RESV
del receptor.
4
El paquete
PATH. Cadarouterpor el que pasa en el camino de vuelta decide si
puede satisfacer la RSpec y la propaga corriente arriba hacia el
emisor, o la rechaza informando corriente abajo al receptor rechazado
5
El receptor tiene que actualizar periodicamente cada 30 segundos la
reserva con mensajes RESV
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 36

30. IETF Integrated services
Funcionamiento de RSVP 37
R
Sender 1
Sender 2
Receiver 1
Receiver 2
R R
R
PATH
PATH
RESV
RESV
RESV (merged)
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 37

31. IETF Integrated services
RSVP: comportamiento con varios receptores
Aprovecha el encaminamiento IP multicast
Multiples receptores, un unico emisor: se fusionan corriente arriba las
reservas de varios receptores corriente abajo
Ejemplo:
El receptor A necesita reserva con retardo<100ms
El receptor B necesita reserva con retardo<200ms
Si un router recibe primero la reserva de A, si puede admitirla, la
propaga corriente arriba hasta llegar al emisor. Si a continuacion recibe
la reserva de B, no hace falta que elrouterpropague corriente arriba
esta segunda reserva pues esta includa en la propagacion que hizo de
la reserva de A.
Ejemplo:
El receptor A necesita reserva con retardo<100ms
El receptor B necesita reserva con retardo<50ms
Si un router recibe primero la reserva de A, si puede admitirla, la
propaga corriente arriba hasta llegar al emisor. Si a continuacion recibe
la reserva de B, comprueba si puede admitido y en caso armativo
propaga dicha reserva hacia el emisor.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 38

32. IETF Integrated services
RSVP: comportamiento con varios emisores
Multiples emisores, multiples receptores:
Los receptores tienen que recoger las TSpecs de todos los
emisores y realizar una reserva sucientemente grande para
todos los emisores
Depende de la aplicacion: en una videoconerencia con 10
participantes podemos suponer que solo 2 hablan a la vez)
receptores reservan para dos emisores y no para 10
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 39

33. IETF Integrated services
RSVP: comportamiento ante fallos derouters
Los protocolos de encaminamiento descubrirannuevas rutas
del emisor al receptor
Los mensajes PATH se envan tambien cada 30 segundos,
pero unrouterlos enva antes si descubre que hay cambios en
su tabla de encaminamiento
En cuanto el receptor reciba el nuevo PATH podra utilizar el
nuevo camino de vuelta corriente arriba para mandar sus
RESV, lo que reestablecera las reservas, caducando
automaticamente las del camino que se abandona
Por tanto RSVP se adapta bien a los cambios en la topologa
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 40

34. DiServ vs IntServ
Contenidos
1
Introduccion
2
IETF Dierentiated Services
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 41

35. DiServ vs IntServ
DiServ vs IntServ
Aislamiento del traco:
DiServ: por clase de traco, agregado de varios ujos.
IntServ: por ujo.
Ambito de QoS:
DiServ: dentro del dominio
IntServ: entre origen y destino
Complejidad en la conguraciojn:
DiServ: conguracion realizada a largo plazo para cada categora, de
forma estatica.
IntServ: conguracion realizada por ujo, en el momento en el que se
necesita, de forma dinamica. Existen mensajes de se~nalizacion entre los
rotures.
Escalabilidad:
DiServ: en los rotures frontera se mantiene informacion para cada
ujo o agregados de ujos, en los rotures del nucleo se mantiene
informacion por cada clase.
IntServ: cada router mantiene informacion de estado por cada ujo.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 42

36. Referencias
Contenidos
1
Introduccion
2
IETF Dierentiated Services
3
IETF Integrated services
4
DiServ vs IntServ
5
Referencias
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 43

37. Referencias
Referencias
James F. Kurose y Keith W. Ross,Redes de Computadores:
un enfoque descendente, Pearson Educacion, 5
a
edicion.
Larry L. Peterson, Bruce S. Davie,Computer networks, a
systems approach, edition 4. Morgan Kaufmann 2007.
Departamento de Sistemas Telematicos y Computacion (GSyC) - Octubre de 2012DiServ e IntServ 44