PDF de programación - Arquitecturas: IntServ

NUEVOS SERVICIOS DE RED EN INTERNET

Área de Ingeniería Telemática

Arquitecturas: IntServ

Área de Ingeniería Telemática

http://www.tlm.unavarra.es



Máster en Comunicaciones







I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Propuestas del IETF

•  DiffServ (Differentiated Services)

–  Filosofía: priorización de tráfico
–  El usuario o un primer equipo de red marca los paquetes con un

–  Los routers van agregando las demandas de los usuarios y

determinado nivel de prioridad

propagándolas por el trayecto

–  Esto le da al usuario una confianza razonable de conseguir la QoS

solicitada

• 

IntServ (Integrated Services)
–  Filosofía: reserva de recursos
–  Cada router del trayecto ha de tomar nota y efectuar la reserva

solicitada

•  Pueden coexistir


a
c
i
t



I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

T
E
N
R
E
T
N

I


N
E

Overview”

el camino

routers

IntServ: Características

•  RFC 1633 : “Integrated Services in the Internet Architecture : an



•  Para cada flujo (puede ser agregado) reserva recursos en todo

•  Soporta control de admisión, llevada a cabo en cada salto
•  Orientado a conexión
•  Requiere un protocolo de señalización que soporten todos los

•  No requiere modificar los protocolos existentes
•  DiffServ no ofrece mecanismos explícitos de CAC
•  Clasificación por flujo empleando las direcciones IP, puertos y

protocolo (5 valores)





I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

IntServ: Servicios

Service”

“commitment … to provide … service closely equivalent to unloaded
best-effort”

Best Effort (análogo al Default PHB DiffServ)
Controlled load service
•  RFC 2211 : “Specification of the Controlled-Load Network Element
•  Para aplicaciones elásticas con requisitos de ancho de banda
•  Análogo a PHB AF DiffServ
• 
•  Prácticamente sin pérdidas
•  No da garantías estrictas
Guaranteed service
•  RFC 2212 : “Specification of Guaranteed Quality of Service”
•  Para aplicaciones inelásticas
•  Análogo a PHB EF DiffServ
•  provides firm (mathematically provable) bounds on end-to-end
•  Garantías de BW
•  Retardo acotado
•  Sin pérdidas en buffers

datagram queueing delays.


a
c
i
t



I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á



T
E
N
R
E
T
N

I


N
E

IntServ: Signaling

•  Requisitos

–  Debe poderse usar en redes IP

•  Emplear tablas de rutas existentes
•  Reaccionar ante cambios de rutas

–  Soportar multicast

•  Flujos que se agregan en árbol

–  Pequeña sobrecarga

•  Pocos mensajes y pequeños

–  Modular y fácil de extender

•  Múltiples protocolos o sistemas de gestión se podrían plantear
•  Resultado:

para ofrecer este servicio

Functional Specification”

–  RFC 2205 : “Resource ReSerVation Protocol (RSVP) – Version 1
–  Es una solución, otras serían posibles pero no se han dado
–  Soft state (periodic updates)
–  No sirve para calcular el camino (no es un routing protocol)

RSVP
•  Directamente sobre IP (protocolo 46)
•  Reservas unidireccionales: bidireccional requiere dos reservas
•  Soporte de multicast: puede agregar reservas en el sentido



I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

hacia la fuente del árbol de distribución multicast

•  Las reservas las inicia el receptor del flujo lo cual ayuda en esa

agregación al ascender en el árbol

“Merging”

Reserva

Versión Header
Length

TOS
16-bit identifier
TTL

46

Longitud
M
F

offset

13-bit fragmentation

D
F

Header checksum

Dirección IP origen
Dirección IP destino

[opciones]

Mensaje RSVP





I

I

D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

RSVP : Path
•  RSVP no es un protocolo de encaminamiento
•  No decide el camino que debe llevar el flujo
•  Los datos seguirán el camino unicast/multicast decidido por

otros protocolos

•  El mensaje RSVP de reserva (Resv) seguiría así el camino

indicado por las tablas de rutas

•  Si las rutas son asimétricas los datos y la reserva no siguen el

mismo camino: ¡ reserva hecha por donde no van los datos !

•  Para resolverlo hay otro tipo de mensaje (Path) que envía la

fuente

Datos

Reserva





I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

RSVP : Path

•  El mensaje Path lo envía la fuente y sigue la ruta calculada por

los protocolos de encaminamiento

•  El mensaje Path sigue el mismo camino que seguirán los datos
•  Este mensaje establece un estado en los routers que soportan

•  El mensaje Resv emplea ese estado para seguir el camino

RSVP en el camino

inverso

•  Si no hay recursos suficientes falla la reserva
•  Falla incluso si existe otro camino que sí disponga de recursos
•  El estado es un “soft state” lo cual quiere decir que se elimina si

no se refresca

•  Los mensajes Path y Resv se envían de forma periódica para

mantener el estado instalado

Path

Resv

RSVP: states
•  Actualizaciones periódicas refrescan el estado
•  Se libera al dejar de recibir actualizaciones
•  Permite adaptarse ante cambios en la topología
•  Permite adaptarse ante cambios en los miembros de un árbol



I



I

D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

de distribución multicast

•  Alternativa (no soportada): Hard state

–  Se mantiene hasta liberarlo explícitamente
–  Requiere algoritmo ante errores





I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E


a
c
i
t



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

RSVP : Parametrización
•  Una reserva consiste viene dada por un “flow descriptor”
•  Un “flow descriptor” está compuesto por un “filter spec” y un

“flow spec”

filterspec (Filter specification)
•  Determina qué paquetes forman el flujo
•  Flujo identificado en base a IPs + puertos + protocolo
•  Permite configurar el clasificador

flowspec (Flow specification)
•  Especifica la QoS deseada y permite configurar el planificador
•  Emplea dos parámetros numéricos
•  TSpec (Traffic specification)

–  Descripción del tráfico
–  Parámetros de un tocken bucket por el que pasa el tráfico
–  Mean rate, tocken bucket depth, max rate, max packet length

•  RSpec (Service Request specification)
–  Requisitos de QoS impuestos a la red
–  BW, retardo, probabilidad de pérdida





I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á


a
c
i
t



T
E
N
R
E
T
N

I


N
E

RSVP e IntServ

•  RFC 2210 : “The Use of RSVP with IETF Integrated Services”
•  Se especifica el contenido de los parámetros de QoS que llevan

los mensajes de RSVP para hacer reservas IntServ

•  RSVP SENDER_TSPEC objects:

–  Viaja en mensaje Path
–  Sender TSpec : descripción del tráfico generada por el emisor
–  Emplea para ello parámetros de token bucket

•  RSVP ADSPEC objects:
–  Viaja en mensaje Path
–  Contienen información modificada por los nodos de la red sobre la

disponibilidad de servicio en el camino

•  RSVP FLOWSPEC objects:

–  Viaje en mensaje Resv
–  Receiver TSpec : descripción del tráfico dada por receptor
–  Receiver RSpec : reserva solicitada por receptor
–  Puede cambiar en la red debido a mergings

Ejemplo de reserva unicast

•  La fuente de los datos envía mensaje Path conteniendo objetos:
–  Sender Template : describe los paquetes para poder clasificarlos

(IPs, puertos)

–  SENDER_TSPEC : descripción del tráfico y por tanto recursos

necesarios
–  ADSPEC
–  PHOP: Previous Hop, dirección IP suya

•  Dirección IP origen de la fuente y destino del receptor
• 

(...)



I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



T
E
N
R
E
T
N

I


N
E



a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Path

Ejemplo de reserva unicast

•  El paquete IP lleva la opción IP Router Alert (RFC 2113) para

que los routers no simplemente conmuten el paquete

•  El router instala el estado que incluye la dirección IP del nodo

upstream (PHOP)

•  Modifica el ADSPEC según sus capacidades y recursos de QoS
•  Reenvía en función de dirección IP destino del paquete IP

(receptor final) y su tabla de rutas

•  Objeto PHOP pasa a ser la dirección IP del interfaz por el que



I

I



D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á



T
E
N
R
E
T
N

I


N
E

reenvía
(...)

• 

Path




I



I

D
E
R
E
D
S
O
C
V
R
E
S
S
O
V
E
U
N



a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

T
E
N
R
E
T
N

I


N
E

Ejemplo de reserva unicast

•  El paquete IP lleva la opción IP Router Alert (RFC 2113) para

que los routers no simplemente conmuten el paquete



•  El router instala el estado que incluye la dirección IP del nodo

upstream (PHOP)

•  Modifica el ADSPEC según sus capacidades y recursos de QoS
•  Reenvía en función de dirección IP destino del paquete IP

(receptor final) y su tabla de rutas

•  Objeto PHOP pasa a ser la dirección IP del interfaz por el que

reenvía

•  Si un router no soporta RSVP reenvía el paquete como un

paquete IP normal