1908 – Arquitectura de Redes

43
1908 – Arquitectura de Redes Tema 6. Calidad de Servicio e Ingeniería de Tráfico Pedro M. Ruiz <[email protected]> Francisco J. Ros <[email protected]> 3º Grado en Ingeniería Informática – 2011/2012

Transcript of 1908 – Arquitectura de Redes

Page 1: 1908 – Arquitectura de Redes

1908 – Arquitectura de Redes

Tema 6. Calidad de Servicio e

Ingeniería de Tráfico

Pedro M. Ruiz

<[email protected]>

Francisco J. Ros

<[email protected]>

3º Grado en Ingeniería Informática – 2011/2012

Page 2: 1908 – Arquitectura de Redes

Organización del tema

� Introducción

� Servicios Integrados (IntServ)

� Servicios Diferenciados (DiffServ)

� Ingeniería de Tráfico

2Arquitectura de Redes - Universidad de Murcia

Page 3: 1908 – Arquitectura de Redes

Organización del tema

� Introducción

� Servicios Integrados (IntServ)

� Servicios Diferenciados (DiffServ)

� Ingeniería de Tráfico

3Arquitectura de Redes - Universidad de Murcia

Page 4: 1908 – Arquitectura de Redes

Definición de QoS

““““La Calidad de Servicio consiste en ofrecer un servicio de

transporte de datagramas predecible a ciertas clases o

tipos de tráfico (flujos) independientemente del resto de

tráficos (flujos) que circulan por la red”

� Consiste en diferenciar los distintos flujos para que cada

uno pueda cumplir los parámetros especificados por sus

requisitos

– Diferenciación

�<IP origen, IP destino, puerto origen, puerto destino, protocolo>

�Campo DSCP (IPv4), FlowID (IPv6)

– Parámetros

�Ancho de banda sostenido y pico, retardo tolerado, etc.

4Arquitectura de Redes - Universidad de Murcia

Page 5: 1908 – Arquitectura de Redes

¿Por qué necesitamos QoS?

� El servicio ofrecido por Internet hoy en día es un servicio muy variable:

– No ofrece garantías en cuanto a retardos o ancho de banda

– Depende muy directamente del tráfico generado por otros usuarios

– No permite priorizar unos tráficos frente a otros

� Necesitamos

– Dar soporte a las nuevas aplicaciones con requisitos de tiempo real

(telefonía IP, videoconferencia, etc.)

– Garantizar tiempos de respuesta a otras aplicaciones (comercio

electrónico, aplicaciones corporativas, etc.)

– Ofrecer herramientas que permitan a los ISP ordenar y priorizar los tráficos

dentro de sus redes

� En general, necesitamos mecanismos que nos permitan clasificar los

tráficos que atraviesan la red y distribuir los recursos de comunicación

entre ellos.

5Arquitectura de Redes - Universidad de Murcia

Page 6: 1908 – Arquitectura de Redes

¿Qué Necesitamos para Ofrecer QoS en

Redes IP?

Σ

La latencia de propagación

viene dada por el medio: no

se puede cambiar

La latencia de encolado

puede ser controlada por

los mecanismos de QoS

Clasificador

Conformador

de tráfico

Control de

accesoGestor de

políticas

Gestor de colas

(prioridades)

Medidores

6Arquitectura de Redes - Universidad de Murcia

Page 7: 1908 – Arquitectura de Redes

Plano de Control de QoS

� El esquema anterior no nos garantiza QoS extremo a extremo

� Necesitamos mecanismos de control de la QoS– Indicar a la red los requisitos de QoS de las aplicaciones

– Transmitir dichos parámetros a lo largo del camino para que los routers acondicionen sus medidores, clasificadores, colas, etc.

– Gestionar los diferentes flujos de la red

� Modelos de QoS– Ingeniería de tráfico

– IntServ

– DiffServ

Backbone de Internet

Red de ISP

Red

de ISP Red

de ISP

Red

de ISP

Red

de ISP

Red

de ISP

Red de

acceso

Red de

acceso

Red de

acceso

IX

IX

Red de

acceso

End to edge

End to end

Edge to edge

7Arquitectura de Redes - Universidad de Murcia

Page 8: 1908 – Arquitectura de Redes

Organización del tema

� Introducción

� Servicios Integrados (IntServ)

� Servicios Diferenciados (DiffServ)

� Ingeniería de Tráfico

8Arquitectura de Redes - Universidad de Murcia

Page 9: 1908 – Arquitectura de Redes

Visión General

� IntServ fue introducido por el IETF en 1994– Sugiere que la arquitectura actual (más algunas

extensiones) es suficiente para proporcionar QoS extremo a extremo

� Reservas estrictas de ancho de banda por flujo– RSVP (Resource reSerVation Protocol), RFC 2205

– Soporta unicast y multicast

� Control de admisión

� Servicios se dividen en tres categorías. Dentro de cada una, cada flujo se caracteriza por su especificación de tráfico (TSpec).

9Arquitectura de Redes - Universidad de Murcia

Page 10: 1908 – Arquitectura de Redes

Categorías de Servicios

� Tres categorías

– Guaranteed Service (Servicio Garantizado):

�RFC 2212

�Ancho de banda y retardo garantizado. Sin pérdidas en las colas.

�Para tráfico de tiempo real con requisitos estrictos.

– Controlled Load Service (Servicio de Carga Controlada):

�RFC 2211

�Si no hay carga en la red, servicio similar “best effort”.

�Cuando hay carga, asegura que un porcentaje alto de paquetes no incurra en un

alto retardo. Un alto porcentaje de paquetes no se perderá en las colas.

�Para tráfico que necesite un trato mejorado pero tolere cierto nivel de retardo y

pérdidas (p.ej. aplicaciones adaptables de tiempo real).

– Best Effort Service

�Servicio tradicional.

10Arquitectura de Redes - Universidad de Murcia

Page 11: 1908 – Arquitectura de Redes

Caracterización de Tráfico

� El tráfico IntServ se caracteriza a través de los

parámetros de un token bucket

– Muchas fuentes de tráfico se pueden definir

exactamente como un token bucket

– Proporciona una definición concisa de la carga impuesta

por los flujos

– Proporciona los parámetros necesarios para una función

de policing

11Arquitectura de Redes - Universidad de Murcia

Page 12: 1908 – Arquitectura de Redes

Proceso

RSVP

Control de

políticas

ClasificadorGestor de

colas

Control de

admisión

ROUTER

Proceso de

aplicación

Control de

políticas

Agente

RSVP

ClasificadorGestor de

colas

Control de

admisión

HOST

Routing

Flujo de datos Señalización RSVP

Modelo de ReferenciaHost y Router

12Arquitectura de Redes - Universidad de Murcia

Page 13: 1908 – Arquitectura de Redes

Elementos del Modelo de Referencia

� Gestión/Reserva de recursos

– Petición explícita de QoS para un flujo o grupo de flujos

� Control de Admisión

– Decisión de aceptar o no la petición de QoS de acuerdo con los

recursos disponibles

� Clasificador de paquetes

– Asigna cada paquete entrante a una clase de tráfico

� Planificador de paquetes

– Asigna recursos de transmisión a cada paquete saliente,

basándose en la clase de tráfico del paquete

13Arquitectura de Redes - Universidad de Murcia

Page 14: 1908 – Arquitectura de Redes

RSVP

� Protocolo genérico de señalización

� Se usa en IntServ para que los hosts comuniquen sus

necesidades de QoS a los elementos de red

– Soporte unicast y multicast

– Emisores anuncian en mensajes PATH el TSpec de su flujo

– Receptores reservan recursos con mensajes RESV

� Protocolo soft-state

– Requiere refresco periódico, si no las reservas expiran

14Arquitectura de Redes - Universidad de Murcia

Page 15: 1908 – Arquitectura de Redes

Escalabilidad en IntServ/RSVP

� Escalabilidad

�La concentración de tráfico en el núcleo se traduce en un gran

número (¿millones?) de flujos individuales (sesiones RSVP) por

router

�Señalización: proceso PATH/RESV, manteniendo estados, etc ..

�Procesando paquetes: clasificación, encolado, planificación, etc ...

�Es necesario soportar QoS extremo a extremo, pero el núcleo

no es capaz de procesar flujos individuales

¡Es necesario agregar flujos!

¡Demasiados

flujos!

Backbone IP

15Arquitectura de Redes - Universidad de Murcia

Page 16: 1908 – Arquitectura de Redes

Organización del tema

� Introducción

� Servicios Integrados (IntServ)

� Servicios Diferenciados (DiffServ)

� Ingeniería de Tráfico

17Arquitectura de Redes - Universidad de Murcia

Page 17: 1908 – Arquitectura de Redes

Motivación

� La viabilidad de los Servicios Integrados es dudosa– ¿Complejidad?

– ¿Escalabilidad?

– ¿Implantación rápida?

� Necesidades de mercado: mecanismos simples que puedan implantarse rápida e incrementalmente para ofrecer diferenciación de servicios– Poder vender diversos niveles de “buen” servicio, aunque no se

puedan especificar de manera muy concisa

� Premisas iniciales del modelo DiffServ:– Diferenciación de tráfico sencilla

– Mecanismos escalables

– Semántica que interopera a través de distintos dominios administrativos

18Arquitectura de Redes - Universidad de Murcia

Page 18: 1908 – Arquitectura de Redes

Visión General

� Filosofía más simplista, opuesta a IntServ

– DiffServ, RFC 2475.

– No hay reservas, hay prioridades.

– No hay garantías por flujo, se hace un tratamiento diferenciado

agregado.

� Principios básicos

– Los routers frontera etiquetan los datagramas IP entrantes en

función de la política de clasificación del operador.

– Los routers internos procesan cada paquete en función de dicha

marca. Cada valor corresponde a un tratamiento diferenciado (PHB,

Per-Hop Behavior). Consecuencias:

�Procesamiento por flujo en routers frontera: marcado, policing, etc.

�Flujos agregados dentro de la red: routers internos no guardan estado por

flujo (escalabilidad), clasificación más eficiente al depender de un solo campo

(marca).

19Arquitectura de Redes - Universidad de Murcia

Page 19: 1908 – Arquitectura de Redes

Filosofía DiffServ

Backbone de Internet

Red de ISP

Red

de ISP Red

de ISP

Red

de ISP

Red

de ISP

Red

de ISP

Red de

acceso

Red de

acceso

Red de

acceso

IX

IX

Red de

acceso

Control en el

router de salida

Acuerdo entre

ISPs (SLA)

Etiquetado en

el Border RouterSin estado

routers

internos

20Arquitectura de Redes - Universidad de Murcia

Page 20: 1908 – Arquitectura de Redes

Campo DSCabecera IP

– DSCP (Differentiated Services CodePoint)

�RFC 2474

�Reemplaza al byte TOS de IPv4

�Define la QoS obtenida en la red

– Especifica un conjunto reducido y bien definido de clases

21Arquitectura de Redes - Universidad de Murcia

Servicio Class Selector Codepoint

Best Effort 000

AF Service Class 1 001

AF Service Class 2 010

AF Service Class 3 011

AF Service Class 4 100

EF Service 101

Network Control Traffic 11X

Class Selector

DSCP

Not used

Page 21: 1908 – Arquitectura de Redes

Componentes de un Nodo DiffServ

� El perfil de tráfico proporciona reglas para determinar si un paquete está dentro de este perfil o no. Se puede descibir con un token bucket. Es parte del SLA.

� El clasificador clasifica los paquetes entrantes según el campo DSCP. Les proporciona un tratamiento diferenciado (prioridad en la cola, política de descarte, etc.).

� El medidor mide las propiedades temporales del tráfico frente a las del perfil.

� El marcador establece/remarca el DS field a un determinado DSCP. Lo realizan los routers frontera. El valor DSCP depende del SLA.

� El shaper retrasa los paquetes para que el sistema cumpla con el perfil de tráfico.

� El dropper descarta paquetes para que el flujo cumpla el perfil de tráfico.

Clasificador

Medidor

MarcadorShaper/

Dropper

22Arquitectura de Redes - Universidad de Murcia

Page 22: 1908 – Arquitectura de Redes

PHBPer Hop Behavior

� Behavior Aggregate (BA)

– Colección de paquetes con el mismo código DSCP que atraviesan

un enlace en la misma dirección.

� Per-Hop Behavior (PHB)

– Descripción del tratamiento observable externamente que un nodo

le da a un BA.

– La asignación DSCP � PHB no es unívoca, paquetes con distintos

DSCPs pueden tener un mismo PHB.

� PHBs estandarizados

– EF: Expedited Forwarding (Reenvío Urgente), RFC 2598.

– AF: Assured Forwarding (Reenvío Asegurado), RFC 2597.

23Arquitectura de Redes - Universidad de Murcia

Page 23: 1908 – Arquitectura de Redes

Definiciones de PHBsEF y AF

� EF– Usado para servicios e2e con baja pérdida, latencia, jitter, y con

garantía de ancho de banda.

– Ej: servicio “premium”, línea dedicada virtual, etc.

– DSCP recomendado: 101110

� AF– Especifica diversos niveles de garantía de envío de los paquetes

– 4 clases AF, con asignación de recursos

– 3 niveles de precedencias de descarte

– DSCP recomendados: 001PP0 (AF1), 010PP0 (AF2), 011PP0 (AF3), 100PP0 (AF4)

24Arquitectura de Redes - Universidad de Murcia

Page 24: 1908 – Arquitectura de Redes

Dominios DiffServ

Dominio DS1 Dominio DS2

� Nodo frontera (NF)

– Interconecta dominios entre sí

– Condicionado de tráfico según SLA

– Los hosts pueden actuar como NF para sus aplicaciones

� Nodo interior

– Aplica PHB a los paquetes

según su DSCP

Servicio

ofrecido (SLA)

25Arquitectura de Redes - Universidad de Murcia

Page 25: 1908 – Arquitectura de Redes

Organización del tema

� Introducción

� Servicios Integrados (IntServ)

� Servicios Diferenciados (DiffServ)

� Ingeniería de Tráfico

26Arquitectura de Redes - Universidad de Murcia

Page 26: 1908 – Arquitectura de Redes

Definición de Ingeniería de Tráfico

� Forwarding basado en camino más corto (ej: OSPF)

– Soporte limitado de multi-path

– Posible infrautilización de recursos

– No proporciona distinción de QoS

– Decisiones tomadas paquete a paquete

– Soporte limitado de control de congestión

� Ingeniería de Tráfico

““““La capacidad de definir rutas dinámicamente, planificando la

entrega del tráfico según la demanda y optimizando la utilización

de la red.”27Arquitectura de Redes - Universidad de Murcia

Backbone IP

Red 2

Red 1

Red 3

Page 27: 1908 – Arquitectura de Redes

El Problema del Pez

Backbone del ISP

Usuario A

Tarifa premium

Usuario B

Tarifa normal

Usuario C

Usuario A

Tarifa premium

Usuario B

Tarifa normal

Usuario C

Problema:

Solución ATM:

Enlaces de alta capacidad

Enlaces de baja capacidad

El ISP no puede controlar en

X que sólo vaya por la ruta

de alta capacidad el tráfico

dirigido a C desde A y no el

de BA

B

X

A

B

X

C

CBackbone del ISP

Al crear diferentes

PVCs el ISP puede

separar fácilmente el

tráfico de A del de B

Este es un ejemplo de lo

que se denomina

‘‘‘‘Ingeniería de Tráfico’’’’

PVC A-C

PVC B-C

Y

Z

VW

Z

Y

V W

28Arquitectura de Redes - Universidad de Murcia

Page 28: 1908 – Arquitectura de Redes

Control Explícito de Caminos

� Idea: permitir que flujos que vayan hacia el mismo destino puedan seguir caminos diferentes en función del tráfico, criterios administrativos, etc.

� Mecanismos:– Opciones IP (strict/loose source routing)

– Encaminamiento extendido en función de varios campos IP, no sólo la dirección de destino (policy routing, QoS routing)

– Túneles IP

– Multiprotocol Label Switching (MPLS)

Red 2

Backbone IPRed 1

Red 3

Ingeniería de

tráfico

29Arquitectura de Redes - Universidad de Murcia

Page 29: 1908 – Arquitectura de Redes

MPLSIntroducción

� Switches ATM retransmiten paquetes más eficientemente

que routers IP

� Esfuerzos para integrar lo mejor de ambas tecnologías

� Arquitectura MPLS (RFC 3031)

– Label Switched Routers (LSR) encaminan paquetes según la

etiqueta que se les haya asignado.

– Los flujos se agregan en Forwarding Equivalence Classes (FEC).

Cada FEC representa un camino (LSP, Label Switched Path) con

unas restricciones de QoS determinadas.

� Capacidades MPLS

– Soporte QoS

– Ingeniería de tráfico

– Soporte VPN (Virtual Private Network, Red Privada Virtual)

– Soporte multi-protocolo

30Arquitectura de Redes - Universidad de Murcia

Page 30: 1908 – Arquitectura de Redes

αααα ββββ

γγγγδδδδ

αααα - ββββ 5

δδδδ - γγγγ 3

αααα ββββ

αααα 5 ββββ 4

ααααββββ αααα

ββββ

αααα 3 ββββ 2 αααα 2 ββββ 7

ααααββββ

γγγγ

αααα 4 ββββ -

γγγγ 7 ββββ -

5 4

3

2

7

A

B

XC

Y

Z

V W

LSR Frontera de ingreso LSR Frontera de egreso

LSRs Interiores (V, W, Y)

LSPsLabel Infomation Base

(LIB)

LIB LIB

FECs

Routers IP

ordinarios (no

MPLS ‘‘‘‘enabled’’’’)

Router IP ordinario

(no MPLS ‘‘‘‘enabled’’’’)

MPLSArquitectura

31Arquitectura de Redes - Universidad de Murcia

Page 31: 1908 – Arquitectura de Redes

MPLSSoporte QoS

� IntServ no es una solución escalable

� DiffServ no proporciona garantías estrictas de QoS, sólo un

tratamiento diferenciado para flujos agregados

� Redes orientadas a conexión (ATM) proporcionan

soluciones más potentes para garantizar la QoS

� MPLS impone un marco orientado a conexión similar a

ATM

– Más rendimiento al simplificar el proceso de forwarding

– Escalabilidad debido a la agregación en FECs

– El algoritmo de reenvío determina la etiqueta de salida y los

recursos a utilizar (LSP, gestión de colas, etc.)

32Arquitectura de Redes - Universidad de Murcia

Page 32: 1908 – Arquitectura de Redes

MPLSIngeniería de Tráfico, Soporte VPN y Multi-protocolo

� Es difícil retransmitir eficientemente datagramas si

implementamos policy routing: decisión basada en

dirección IP destino y políticas locales.

� Problema crítico en enlaces troncales de Internet.

� ATM resuelve el problema fijando la ruta al crear el CV.

� MPLS resuelve el problema asociando la ruta (LSP) a la

etiqueta correspondiente.

– La etiqueta representa la FEC del flujo de datos.

� Soporte VPN

– Las etiquetas se pueden apilar

– Equivalente a crear un túnel

� Soporte multi-protocolo: IP, ATM, Frame Relay, etc.

33Arquitectura de Redes - Universidad de Murcia

Page 33: 1908 – Arquitectura de Redes

Clasificación del Tráfico en FECs

� Se puede efectuar en base a diferentes criterios,

p.ej:

– Dirección IP origen y/o destino

– Número de puerto origen y/o destino

– Campo protocolo de IP (TCP, UDP, ICMP, etc.)

– Valor del campo DSCP de DiffServ

– Etiqueta de flujo en IPv6

� Esta función sólo se realiza en el router de entrada

al dominio MPLS

� El resto de LSRs sólo tienen en cuenta la etiqueta

asignada34Arquitectura de Redes - Universidad de Murcia

Page 34: 1908 – Arquitectura de Redes

Creación de los LSP

� Un protocolo IGP intercambia información de enrutamiento y alcance– Se usan protocolos de estado de enlace (OSPF, IS-IS), que

permiten conocer la ruta completa y por tanto fijar reglas de ingeniería de tráfico.

– Si una vez fijado el LSP falla algún enlace, se recalcula la ruta.

� Una vez calculado el LSP para una FEC, hace falta asignarle etiquetas y distribuirlas. Opciones:– Configuración estática (equivalente a los PVCs en ATM)

– Descubrimiento dinámico mediante un protocolo de señalización:

�LDP: Label Distribution Protocol

�RSVP-TE: extensión a RSVP para Traffic Engineering

�…

� Las etiquetas sólo tienen significado local

35Arquitectura de Redes - Universidad de Murcia

Page 35: 1908 – Arquitectura de Redes

Asegura que LSRs vecinos tienen una visión coherente

de las asociaciones entre FECs y etiquetas

Routing Table:

Addr-prefix Next Hop

47.0.0.0/8 LSR2

LSR1 LSR2 LSR3

IP Packet 47.80.55.3

Routing Table:

Addr-prefix Next Hop

47.0.0.0/8 LSR3

For 47.0.0.0/8

use label ‘17’

Label Information Base:

Label-In FEC Label-Out

17 47.0.0.0/8 XX

Label Information Base:

Label-In FEC Label-Out

XX 47.0.0.0/8 17

Paso 1: LSR crea asociación

entre FEC y valor de etiqueta

Paso 2: LSR informa de la

asociación al LSR adjacentePaso 3: LSR inserta valor

de etiqueta en la LIB

Se puede usar piggybacking sobre un protocolo de routing

existente, o un protocolo específico

Necesidad de Distribuir Etiquetas

36Arquitectura de Redes - Universidad de Murcia

Page 36: 1908 – Arquitectura de Redes

Etiquetas MPLS

� MPLS funciona sobre multitud de tecnologías de nivel de enlace: líneas dedicadas (PPP), LANs, ATM o Frame Relay.

� En ATM y Frame Relay la etiqueta MPLS ocupa el lugar del campo VPI/VCI o en el DLCI

� La etiqueta MPLS se coloca delante del paquete de red y detrás de la cabecera de nivel de enlace.

� Las etiquetas pueden anidarse, formando una pila. Esto permite ir agregando (o segregando) flujos. El mecanismo es escalable.

37Arquitectura de Redes - Universidad de Murcia

Page 37: 1908 – Arquitectura de Redes

Etiqueta Exp S TTL

Bits → 20 3 1 8

Etiqueta:

Exp:

S:

TTL:

La etiqueta propiamente dicha que identifica una FEC (con

significado local).

Bits para uso experimental; una propuesta es transmitir en ellos

información de DiffServ.

Vale 1 para la primera entrada en la pila (la más antigua), cero

para el resto.

Contador del número de saltos. Este campo reemplaza al TTL de

la cabecera IP durante el viaje del datagrama por la red MPLS.

Formato Etiqueta MPLS

38Arquitectura de Redes - Universidad de Murcia

Page 38: 1908 – Arquitectura de Redes

Cabecera

PPP

Pila de etiquetas

MPLS

Cabecera IP Datos Cola PPP

Cabecera

MAC

CabeceraL

LC

Pila de etiquetas

MPLS

Cabecera IP Datos Cola MAC

Etiqueta MPLS

Superior

Resto de etiquetas

MPLS

Cabecera IP Datos

Etiqueta MPLS

Superior

Resto de etiquetas

MPLS

Cabecera IP Datos Cola Frame

Relay

Cabecera Frame Relay

Campo DLCI

Cabecera ATM

Campo VPI/VCI

PPP

(Líneas dedicadas)

LANs (802.2)

ATM

Frame Relay

Situación Etiqueta MPLS

39Arquitectura de Redes - Universidad de Murcia

Page 39: 1908 – Arquitectura de Redes

Tratamiento del Campo TTL

� Al entrar un paquete en la red MPLS, el router de ingreso inicializa el

TTL de la etiqueta al mismo valor que tiene en ese momento la

cabecera IP.

� Durante el viaje del paquete por la red MPLS el campo TTL de la

etiqueta disminuye en uno por cada salto. El de la cabecera IP no se

modifica.

� A la salida, el router de egreso coloca en la cabecera IP el valor del

TTL que tenía la etiqueta, menos uno.

� Si en algún momento el TTL vale 0 el paquete es descartado.

� Si hay etiquetas apiladas solo cambia el TTL de la etiqueta situada más

arriba. Cuando se añade una etiqueta hereda el valor de la anterior en

la pila, cuando se quita pasa su valor (menos uno) a la que tenía

debajo.

40Arquitectura de Redes - Universidad de Murcia

Page 40: 1908 – Arquitectura de Redes

Red MPLS

ISP A

Red MPLS

ISP B

Red MPLS

ISP C

4 (16)

8 (12)

2 (15)

2 (13)

2 (15)

7 (14)

LSR de Ingreso

1er nivelLSR Interior

1er nivel

LSR Interior

1er nivel LSR de Egreso

1er nivel

LSR de Egreso

2º nivel

LSR de Ingreso

2º nivel

V

W

X

Y

Z

U

Los routers U y Z han constituido un

LSP con dos LSR interiores, V e Y.

Los routers V e Y están enlazados por un LSP que ha creado

el ISP B. V e Y no ven las etiquetas rojas que manejan W y X.

Para el ISP B parece como si V e Y fueran

routers IP ordinarios (no MPLS ‘‘‘‘enabled’’’’).

2 (15)

7 (14) Etiqueta (TTL) de 2º nivel

Etiqueta (TTL) de 1er nivel

En cierto modo es como si entre V e Y se hubiera hecho un túnel que atravesara W y X.

IP (17)

IP (11)

IP (17) Paquete IP (TTL)

Apilamiento de Etiquetas MPLS

41Arquitectura de Redes - Universidad de Murcia

Page 41: 1908 – Arquitectura de Redes

Resumen Aplicaciones de MPLS

� Redes de alto rendimiento: las decisiones de encaminamiento que han de tomar los routers MPLS en base a la LIB son mucho más sencillas y rápidas que las que toma un router IP ordinario (la LIB es mucho más pequeña que una tabla de rutas normal). La anidación de etiquetas permite agregar flujos con mucha facilidad, por lo que el mecanismo es escalable.

� Ingeniería de Tráfico: se conoce con este nombre la planificación de rutas en una red en base a previsiones y estimaciones a largo plazo con el fin de optimizar los recursos y reducir congestión.

� QoS: es posible asignar a un cliente o a un tipo de tráfico una FEC a la que se asocie un LSP que discurra por enlaces con bajo nivel de carga.

� VPN: la posibilidad de crear y anidar LSPs da gran versatilidad a MPLS y hace muy sencilla la creación de VPNs.

� Soporte multiprotocolo: los LSPs son válidos para múltiples protocolos, ya que el forwarding de los paquetes se realiza en base a la etiqueta MPLS estándar, no a la cabecera de nivel de red.

42Arquitectura de Redes - Universidad de Murcia

Page 42: 1908 – Arquitectura de Redes

Bibliografía

� Básica

– Stallings, “High Speed Networks and Internets”, Cap. 17

y 18.

– Z. Wang. “Internet QoS: Architectures and Mechanisms

for Quality of Service”, The Morgan Kaufmann Series in

Networking, 2001, cap. 4 y 5

43Arquitectura de Redes - Universidad de Murcia

Page 43: 1908 – Arquitectura de Redes

Bibliografía

� Complementaria

– Grenville Armitage, “Quality of Service in IP Networks”,

McMillan Technical Publishing, 2000, capítulos 4 y 5.

– X. Xiao, L.M. Li, “Internet QoS: the Big Picture,” IEEE

Network, vol. 13, no. 2,pp. 1-13, March 1999

– B. Davie, Y. Rekhter, “MPLS Technology and

Applications,” Morgan Kaufmann,2000.

– RFC 3031: MPLS Architecture

– RFC 3032: MPLS Label Stack Encoding

44Arquitectura de Redes - Universidad de Murcia