1.1 PERSPECTIVA HISTRICA

En slo unos pocos aos, el MultiProtocolo de Conmutacin de etiquetas (MPLS) ha pasado de ser

una tecnologa extica a una herramienta corriente principal utilizado por los proveedores de

servicios para crear servicios lucrativos. Hay un rpido despliegue de los servicios habilitados en

MPLS y desarrollo activo de nuevos mecanismos y aplicaciones de MPLS en los organismos de

normalizacin.

Contiene cuatro artculos que el grupo tena como objetivo abordar a travs del desarrollo de

MPLS. Es interesante examinar estos para ver qu artculos estn siendo relevante hoy en da:

1. Escalabilidad de enrutamiento de capa de red. El uso de etiquetas como un medio para agregar

informacin de reenvo, mientras se trabaja en presencia de jerarquas de enrutamiento. VPN de

capa 3 han demostrado ser un buen ejemplo de agregacin de la transmisin de informacin.

Los routers de borde deben contener la informacin de enrutamiento correspondiente a cada V PN

que el servicio, pero los routers de ncleo no lo hacen. Por lo tanto, suponiendo que los servicios

encaminador de borde slo un subconjunto de las VPNs pertenecientes a la red, no router en la

red necesita para mantener todo el conjunto de rutas presentes en la red.

2. Una mayor flexibilidad en la prestacin de servicios de enrutamiento. El uso de etiquetas para

identificar especial de trfico que van a recibir servicios especiales, por ejemplo, QoS. El uso de

etiquetas para proporcionar el reenvo a lo largo de una ruta explcita diferente de la construida

por el reenvo de base destino. MPLS tiene la capacidad de identificar determinados flujos de

trfico que deben recibir servicios especiales, tales como Calidad de Servicio (QoS). Tambin tiene

propiedades de ingeniera de trfico que le permiten proporcionar reenvo a lo largo de una ruta

explcita particular.

3. Aumento del rendimiento. Utilizando el paradigma etiqueta de intercambio para optimizar el

rendimiento de la red. Debido a que los routers modernos realizan el reenvo de paquetes en

hardware, las tasas de transmisin de paquetes IP y MPLS son similares. Sin embargo,

'rendimiento de la red de optimizacin' implica un contexto ms amplio que simplemente el

rendimiento de los nodos individuales. Ciertamente MPLS ha ayudado en este contexto ms

amplio, por ejemplo, mediante el uso de la ingeniera de trfico para evitar la congestin y el uso

de redireccionamiento rpido para reducir la interrupcin al trfico cuando un enlace en la red

falla.

4. Simplifique la integracin de routers con tecnologas basadas en conmutacin de celdas:

a) hacer conmutadores celulares se comportan como iguales a los routers (reduciendo as el

nmero de pares de enrutamiento que un router tiene que mantener), b) por lo que la

informacin sobre topologa fsica disponible para los procedimientos de enrutamiento de capa de

red, y

C) Por emplear procedimientos de direccionamiento, ruteo y administracin comunes.

Cuando este elemento en el enunciado del problema fue escri to, muchas redes tenan un ncleo de

modo de transferencia asncrono (ATM) de conmutadores rodeados de routers. Los routers se

suelen mallar plenamente en conexiones ATM. Este modelo de superposicin estaba resultando

difcil para escalar porque el nmero de adyacencias de enrutamiento necesarios creci como el

cuadrado del nmero de routers involucrados; por lo tanto no era un requisito para que los

conmutadores ATM acten como pares a los routers. Es interesante observar que la situacin se ha

vuelto del revs: ahora muchas redes tienen un ncleo basado en MPLS, y los proveedores de

servicios estn migrando servicios ATM a esta red central mediante la interconexin de los

conmutadores ATM capa 2 con conexiones sobre el ncleo MPLS! Esto tiene el problema de que el

nmero de adyacencias entre conmutadores ATM crece como el cuadrado del nmero de

conmutadores ATM involucrados. Por lo tanto, actualmente hay trabajo en la fabricacin de

conmutadores ATM que se comportan como compaeros a los routers MPLS ALLI.

Esto es para evitar tener una malla completa de adyacencias entre conmutadores ATM ms que

para evitar tener una malla completa de adyacencias entre los routers, como se indica en el

enunciado del problema. El concepto expresado en el enunciado del problema de la utilizacin de

MPLS como un plano de control para mltiples tecnologas se ha manifestado en forma generalizada

MPLS (GMPLS).

En GMPLS, un plano de control comn abarca una amplia gama de dispositivos de red, tales como

routers, conmutadores ATM, SONET / SDH equipos y conexiones cruzadas pticas [RFC3945].

En resumen, gran parte de la declaracin del problema original es an relevante hoy. Muchos de los

mecanismos de MPLS descritos en la parte 1 de este libro fueron desarrollados para hacer frente a

las cuestiones antes mencionadas, en beneficio de las aplicaciones MPLS discutidos en la Parte 2 de

este libro.

1.2 TENDENCIAS ACTUALES

En el momento de escribir este libro, el servicio MPLS visible al cliente ms utilizada es la VPN de

nivel 3 (tambin conocido como una VPN IP o 2547bis VPN, despus de que el documento IETF los

describe). MPLS tambin se utiliza en algunas redes como una herramienta de infraestructura para

proporcionar la ingeniera de trfico y las capacidades de rpido clculo de la ruta.

Otra aplicacin es en rpido crecimiento de transporte punto a punto de la capa 2, ya sea como

medio de transporte de trfico Ethernet de un cliente a travs del rea amplia o como un

componente de ATM o Frame Relay con emulacin de servicios.

Por ltimo, el servicio de LAN virtual privada (VPLS) ofertado, en la que el proveedor de servicios da

la impresin al cliente de que sus sitios estn conectados a la misma red de rea local (LAN), tambin

se estn haciendo disponibles.

Muchos proveedores de servicios estn investigando la posibilidad de utilizar una red basada en

MPLS para proporcionar una plataforma comn para una amplia gama de servicios que actualmente

se suministran a travs de mltiples redes distintas. Dicha red multiservicio podra llevar trafico de

PSTN, Internet y servicios de datos IP privadas, servicios Capa 2 ATM y Frame Relay, Broadcast TV y

trfico TDM. Esto supone un ahorro de capital y costos operativos a los operadores de redes,

permitindoles operar una sola red en lugar de una red separada para cada tipo de servicio. Un

objetivo fundamental de este libro es mostrar cmo MPLS puede proporcionar los mecanismos

necesarios para esta convergencia de redes, por ejemplo, mediante el uso de Diffserv Ingeniera de

Trfico (TE), que permite a la red MPLS proporcionar caractersticas de conexin orientada a los

flujos de trfico particular.

1.3 MECANISMOS MPLS

En esta seccin se ofrece una visin general de los mecanismos que sustentan MPLS. Los lectores

que estn familiarizados con estos pueden saltarse esta seccin.

Una propiedad fundamental de una red MPLS es que puede ser utilizado para tunelar mltiples tipos

de trfico a travs del ncleo de la red.

Tunneling es una herramienta poderosa porque slo los routers en la entrada y la salida del tnel

necesitan entender el "contexto" del trfico subyacente llevado sobre el tnel (por ejemplo, el

protocolo que pertenece a el trfico y la informacin de accesibilidad necesaria para la ruta y

remitirlo en su forma nativa). Este detalle se oculta de routers en el ncleo de la red. Como

consecuencia, los dispositivos de ncleo slo necesitan un estado para llevar suficiente puedan

conmutar paquetes encapsulados en MPLS sin tener en cuenta su contenido subyacente.

Adems de estas propiedades de agregacin, que se aplican a los tneles en general, tneles MPLS

tienen las siguientes propiedades particulares:

1. El trfico puede ser enrutado de forma explcita, dependiendo de qu protocolo de sealizacin

se utiliza.

2. La recursividad se proporciona; por lo tanto, pueden existir tneles dentro de tneles.

3) Hay proteccin contra suplantacin de datos, como el nico lugar donde los datos pueden ser

inyectados en un tnel MPLS que est en el extremo del comienzo de dicho tnel. En contraste, los

datos pueden ser inyectados en un tnel IP de cualquier fuente que tenga conectividad a la red que

lleva el tnel.

4) La sobrecarga de encapsulacin es relativamente baja (4 bytes por cabecera MPLS).

Una red MPLS consiste en dispositivos de borde conocidos como Label Edge Router (LER) o routers

Provider Edge (PE) y routers de ncleo conocidos como Label Switching Routers (LSRs) o un router

proveedor (P). Una malla de tneles unidireccionales, conocidos como Label Switched Paths (LSP)

se construye entre los LERs con el fin de que un paquete que entra en la red en la entrada LER puede

ser transportado a la LER de salida apropiada. Cuando los paquetes entran en una red, el router

entrada determina qu clase de equivalencia de reenvo (FEC) pertenecen los paquetes. Los

paquetes que se entregarn en el mismo punto de salida en la red por el mismo camino y con el

mismo tratamiento de envo a lo largo de ese camino se dice que pertenecen a la misma FEC. Los

paquetes que pertenecen a la misma FEC se reenvan con la misma etiqueta MPLS. En un caso

sencillo, paquetes cuyas direcciones de destino corresponden al mismo Border Gateway Protocol

(BGP) del siguiente salto son considerados por el router de ingreso como pertenecientes a la misma

FEC. En otros casos, puede haber una asignacin ms granular de paquetes a FECs. Por ejemplo, en

Diffserv TE, cada punto de salida en la red puede tener mltiples FECs, cada uno perteneciente a

una clase de trfico diferente.

Es el papel del LER de entrada para determinar el LER de salida apropiado y el LSP a la LER de salida

asociado con el FEC. MPLS tiene la propiedad de que mltiples tipos de trfico pueden ser

multiplexados en un nico LSP. Por lo tanto, si se desea por el operador de red, un nico LSP se

puede utilizar para llevar a todo el trfico (por ejemplo, L3 VPN, IP pblica y la Capa 2) entre un LER

de entrada particular y un LER de salida particular. Los routers de trnsito a lo largo de la trayectoria

de la LSP hacen su decisin de envo a partir de una cabecera MPLS de formato fi jo, y por lo tanto

no necesitan almacenar rutas (rutas L3 VPN, rutas IP externas, de capa 2 informacin reenvo)

pertenecientes a los subyacentes paquetes de tnel. Esta es una propiedad de escala importante,

ya que de lo contrario cada uno de los routers de ncleo tendra que llevar la informacin de

enrutamiento equivalente a la suma de la informacin de enrutamiento realizado por todos los

routers de frontera de red.

Las siguientes secciones describen el plano fundamental de reenvo y los mecanismos de control de

planos que sustentan MPLS.

1.3.1. MECANISMOS DEL PLANO DE REENVO

Los datos llevadas a travs de una red MPLS tiene una o ms cabeceras MPLS aplicados con el fin de

transportar a travs de la red. La estructura de la cabecera MPLS se muestra en la Fig 1.1. Contiene

los siguientes campos:

1. Un valor de la etiqueta de 20 bits. Paquetes MPLS se reenvan sobre la base de este

campo. Este valor se utiliza como un ndice en la tabla de reenvo de MPLS.

2. campo EXP (3 bits). Estos bits se conocen como los bits experimentales. En la prctica, se

utilizan para transmitir la clase de servicio que debe aplicarse al paquete. Por ejemplo, LSRs

y LER pueden utilizar estos bits para determinar la cola en la que el paquete debe ser

colocado. Tenga en cuenta que en algunos casos, como se describe ms adelante en este

captulo, el valor de la etiqueta MPLS tambin determina el comportamiento de cola

aplicada al paquete.

3. Parte inferior de bits pila (bit S). Como se describe ms adelante en este captulo, las

cabeceras MPLS se pueden apilar. El bit S se establece en la cabecera del paquete de MPLS

en la parte inferior de la pila.

4. Time-to-live (TTL). Esto se utiliza para evitar bucles de reenvo y tambin se puede utilizar

para la ruta de trazado. El valor se reduce en cada salto y el paquete se descarta si el valor

de llegar a cero.

Los paquetes que llegan a la red tienen uno o ms cabeceras MPLS aplicadas por el LER de

entrada. La LER de entrada identifica el LER de salida a la que se debe enviar el paquete y el

LSP correspondiente. El valor de la etiqueta utilizada corresponde al LSP al que se coloca el

paquete. El siguiente router realiza una bsqueda de esa etiqueta y determina la etiqueta

de salida que se debe utilizar para la siguiente etapa de la LSP. La operacin de bsqueda

en un router P implica la lectura de la etiqueta de entrada;

La operacin de bsqueda en un router P implica la lectura de la etiqueta de entrada; esto produce un nuevo valor de: la etiqueta a usarse y de la interfaz (s) de salida en el que se debe remitir el paquete. De esta manera, a travs de este paradigma de intercambio de etiqueta, el paquete es transportado a lo largo de la LSP desde la entrada a la LER hasta la salida. En algunos casos simples, el uso de una sola etiqueta MPLS es suficiente, por ejemplo, al transportar trfico IP pblico a travs de una red. En este caso, una vez que el paquete llega al LER de salida, el LER realiza una consulta IP normal con el fin de determinar qu enlace de salida debe utilizar. Por lo general, se utiliza un sistema denominado Penltimo Salto Popping (PHP). En este esquema, el LSR antes del LER de salida (es decir, el penltimo enrutador a lo largo de la LSP) retira la etiqueta MPLS y se enva al LER de salida como un paquete IP. Esto simplifica el procesamiento requerido en el nodo de salida, de lo contrario sera necesario retirar la etiqueta y realizar una bsqueda IP en el nodo de salida. En otros casos, una nica cabecera MPLS es insuficiente. Esto es porque los LER en una red particular pueden estar involucrados en mltiples servicios - VPN Capa 3, VPN Capa 2, VPLS - en lugar de slo la direccin IP pblica. En este caso, el LER de salida necesita saber qu servicio y la instancia de ese servicio (es decir, qu cliente) pertenece el paquete. Esto se logra teniendo una cabecera MPLS adicional, que se aplica en el LER de entrada, correspondiente al servicio y la instancia de servicio al que el paquete debe ser dirigido por el LER de salida una vez que el paquete ha cruzado la red. Esto se ilustra en la Figura 1.2. Veamos cmo se transporta un paquete MPLS con dos cabeceras entre los LERs de ingreso y de

salida. La cabecera interior con etiqueta Y designa la instancia de servicio y el servicio, y la cabecera exterior, a menudo llamado el encabezado de transporte, es la requerida para el transporte del paquete del LER de entrada, PE1, al correcto LER de salida, PE2. Por ejemplo, un LER particular puede estar ejecutando varios VPN Capa 3, VPLS y VPN de Capa 2. La etiqueta Y le dice al LER de salida que el paquete en cuestin corresponde al servicio de VPN capa 3 que se proporciona a la empresa A, en lugar de cualquiera de los otros.

VPN Capa 3 VPLS VPN capa 2. La capacidad de apilar los encabezados de esta manera da la clave de multiplexacin y propiedades jerrquicas de MPLS, lo que permite un solo LSP entre un punto de entrada y salida en particular para llevar a todo el trfico entre esos puntos. Como se muestra en la figura 1.3, el paquete sale de la LER de entrada, PE1, con un valor de etiqueta interior de Y y un valor de etiqueta exterior de X. Los routers P1 y P2 realizar una bsqueda basada en la etiqueta de transporte externo y no necesitan leer o tomar cualquier accin basada en la etiqueta interior. P1 cambia la etiqueta exterior X con etiqueta exterior W. Si PHP est en uso, que es tpicamente el caso, el router P2 retira la cabecera externa, y enva el resto del paquete a PE2. As, cuando el paquete llega a PE2, la etiqueta ms externa (y nica), es la etiqueta interior original, Y, que PE2 utiliza para identificar el paquete como perteneciente a la instancia VPN Capa 3 perteneciente a la empresa A. Cmo sabe el LER de entrada el valor (es) etiqueta de usar? La etiqueta de transporte se aprende a travs de protocolos, ya sea el de RSVP o sealizacin LDP, que se describen con ms detalle ms adelante en este captulo. La etiqueta interior en el caso de la mayora de los servicios se aprende a travs de BGP (por ejemplo VPN de capa 3, BGP-sealizado VPN capa 2). Sin embargo, tambin hay casos donde se utiliza LDP, por ejemplo, en los circuitos de transporte PLD sealizados capa 2. 1.3.1.1 Soporte MPLS de DiffServ DiffServ fue desarrollado como una solucin para proporcionar Calidad de Servicio (QoS). Lo hace dividiendo el trfico en un pequeo nmero de clases y la asignacin de recursos de la red en una base por clase. Para evitar la necesidad de un protocolo de sealizacin, la clase est marcada directamente dentro de la cabecera del paquete.

MPLS Soporte de Servicios Diferenciados (DiffServ)

DiffServ fue desarrollado como una solucin para proporcionar Calidad de Servicio (QoS). Esto lo hace dividiendo el trfico en un pequeo nmero de clases y la asignacin de recursos de la red en una base por clase. Para evitar la necesidad de un protocolo de sealizacin, la clase es marcada directamente dentro de la cabecera del paquete.

Figura: Reenvo de un paquete que tiene dos cabeceras MPLS

La solucin DiffServ estaba dirigido a las redes IP por lo que la marca es en el campo de 6 bits Cdigo

DiffServ Point (DSCP) en la cabecera IP. El DSCP determina el comportamiento QoS de un paquete

en un nodo en particular en la red. Esto se llama el comportamiento por salto (Per-Hop Behavior)

(PHB) y se expresa en trminos de la planificacin y retirar la preferencia que experimenta un

paquete. Desde un punto de vista de la implementacin, el PHB se traduce en la cola de paquetes

utilizado para el reenvo, la probabilidad de prdida en caso de que la cola exceda un cierto lmite,

los recursos (buffers y ancho de banda) asignados a cada cola y la frecuencia con la cual es revisada

una cola.

El primer desafo con el apoyo DiffServ en una red MPLS es que los LSRs toman sus decisiones de

envo basados en la cabecera MPLS solo, por lo que el comportamiento por salto (PHB) debe ser

deducida de la misma.

El IETF resolvi este problema mediante la asignacin de los tres bits experimentales (EXP) en la

cabecera MPLS para transportar informacin de DiffServ en MPLS.

Esta solucin resuelve el problema inicial de transmitir el PHB deseado en la cabecera MPLS, al

tiempo que introduce una nueva: cmo evala DSCP un mapa expresado en un campo de 6 bits

que puede codificar hasta 64 valores en un campo EXP de 3 bits que puede transportar hasta ocho

valores distintos? Hay dos soluciones a este problema, que se analizarn por separado ms adelante.

La primera solucin se aplica a las redes que soportan menos de ocho PHBs. Aqu, el mapeo es

sencillo: un DSCP en particular es equivalente a una combinacin EXP particular y mapea a un PHB

en particular (la planificacin y la prioridad). Durante el envo, la etiqueta dete rmina dnde enviar

el paquete y los bits EXP determinan el PHB. Los bits EXP no son una propiedad que es marcada

cuando se establece la ruta de etiquetas conmutadas- label-switched path (LSP); el mapeo de EXP

para PHB se configura en cada nodo de la red.

Los bits EXP pueden ser configurados de acuerdo a los bits DSCP de los paquetes IP transportados

en el LSP, o pueden ser fijados por el operador de la red. Los LSPs para los que el PHB se infiere a

partir de los bits EXP son llamados E-LSP (donde E significa EXP-inferido'). Los E-LSPs pueden llevar

paquetes con hasta ocho distintos comportamientos por salto en un solo LSP.

La segunda solucin se aplica a las redes que soportan ms de ocho PHBs. En este caso, los bits EXP

no pueden llevar toda la informacin necesaria para distinguir entre PHBs. El nico otro campo en

la cabecera MPLS que se puede utilizar para este propsito es la propia etiqueta. Durante el envo,

la etiqueta determina dnde enviar el paquete y qu comportamientos de planificacin se le

otorgar, y los bits EXP transmiten informacin con respecto a la prioridad asignada a un paquete.

As, el PHB se determina a partir de la etiqueta y los bits de EXP.

Debido a que la etiqueta est vinculada implcitamente a un comportamiento por salto, esta

informacin debe ser transmitida cuando el LSP es sealado. Los LSPs que utilizan la etiqueta para

transmitir informacin sobre el PHB deseado se llaman L-LSP (donde L significa etiqueta-inferida).

Los L-LSPs pueden llevar paquetes de un solo PHB o de varias PHBs que tienen el mismo rgimen de

planificacin, pero difieren en sus prioridades (por ejemplo, el conjunto de clases AFxy donde x es

una constante, son tratados de la misma manera desde el punto de vista de la planificacin, pero

difieren en su prioridad de acuerdo con el valor de y). La Tabla 1.1 resume las diferencias entre E-

LSP y L-LSP.

E-LSP L-LSP

El PHB es determinado por los bits EXP El PHB es determinado por el campo etiqueta o por la combinacin de los campos etiqueta y los bits EXP

Puede transportar trfico con ms de 8 PHBs distintos en un solo LSP

Un solo PHB por LSP o varios PHBs con el mismo rgimen de planificacin y diferentes prioridades

Conservador uso de la etiqueta y el mantenimiento del estado, porque la etiqueta slo se utiliza para transportar informacin de la ruta

Utiliza ms etiquetas y mantiene ms estados, porque la etiqueta transmite informacin sobre la ruta y el comportamiento de planificacin

No se requiere la sealizacin para transmitir la informacin PHB

La informacin PHB necesita sealizacin cuando se establece el LSP

Hasta 8 PHBs pueden ser soportados en la red cuando slo se utilizan E-LSP. E-LSP se puede utilizar en conjunto con L-LSP cuando se requieren ms PHBs

Cualquier nmero de PHBs pueden ser soportados en la red...

Hasta ahora hemos visto cmo MPLS utiliza etiquetas para el reenvo, pero cmo son los enlaces

entre las etiquetas y FECs distribuidos toda la red? Dado que la configuracin manual no es una

opcin, existe una clara necesidad de un protocolo para difundir esta informacin. Desde un punto

de vista prctico, hay dos opciones:

(a) Inventar un nuevo protocolo para la distribucin de las ligaduras de etiqueta o

(b) Ampliar un protocolo existente para llevar etiquetas, adems de la informacin de

enrutamiento. La cuestin de si se debe inventar un nuevo protocolo o extender una

existente es muy popular en el mundo MPLS, y se lo discutir en detalle en los captulos

posteriores. En este punto. En cuanto a la distribucin de las cadenas de las etiquetas, la

ingeniera comunidad invent un nuevo protocolo (LDP o distribucin de etiquetas Dos

protocolos de protocolo) y extendidos existentes (de RSVP, o de recursos Reserva

Protocolo, y BGP, o Border Gateway Protocol). Los formatos de paquetes y

funcionamiento bsico de estos protocolos se explican en detalle en muchos textos

introductorios [Doyle Kolon, Osborne Simha]. En vez de repetir esta informacin aqu,

vamos a examinar en lugar las propiedades de los diferentes protocolos y ver los

beneficios y limitaciones de cada uno de ellos.

1.3.2.1 LDP

LDP [RFC3036] es el resultado del Grupo de Trabajo MPLS [MPLS WG] en la IETF. A diferencia de

RSVP o BGP, que exista antes MPLS y se extendieron a hacer distribucin de etiquetas, LDP fue

especficamente diseado para distribuir etiquetas en la red. Desde el objetivo del LDP es la

etiqueta de distribucin, LDP no intenta realizar funciones de enrutamiento y se basa en una

puerta de enlace interior Protocol (IGP) para todas las decisiones relacionadas con el

enrutamiento. La especificacin original LDP se defini para la creacin de LSP para FECs que

representa una direccin IPv4 o IPv6. Esta es la funcionalidad que se describe en esta seccin. Las

extensiones de LDP utilizados para pseudowire y la sealizacin VPLS ser discutido los captulos.

LDP fue diseado con la finalidad para extenderse fcilmente. Toda la informacin intercambiada

en LDP se codifica como TLV (tipo-longitud-valor). El tipo y longitud estn en el inicio de la

codificacin, y su longitud se conoce de antemano. El tipo de informacin que identifica es

intercambiado y determina cmo el resto de la codificacin es para ser entendido. El valor se

intercambia la informacin real y la longitud es la longitud del campo de valor. TLV hacen que sea

fcil para: (a) aadir nuevas capacidades mediante la adicin de un nuevo tipo y (b) omitir

desconocido objetos al ignorar la cantidad de datos que se especifican en el campo de longitud.

Con los aos, se han aadido muchas nuevas capacidades para el protocolo Gracias a la

incorporacin de la extensin.

Operacin LDP es impulsado por el intercambio de mensajes entre pares. Pares potenciales,

tambin conocidos como los vecinos, son automticamente descubiertos a travs de mensajes de

saludo multidifusin UDP a un conocido puerto. El protocolo tambin permite el descubrimiento

de interlocutores remotos utilizando mensajes de hola dirigidos. Una vez que se descubre un

compaero potencial, un TCP se establece la conexin a la misma y una sesin LDP se establezca.

En sesin de tiempo de inicializacin, los interlocutores intercambian informacin sobre las

caractersticas y modo de funcionamiento que apoyan. Despus de la sesin de configuracin, los

interlocutores intercambian informacin con respecto a la unin entre etiquetas y FECs travs de

la conexin TCP. El uso de TCP garantiza la entrega fiable de la informacin y permite

incrementales actualizaciones, en lugar de actualizaciones peridicas. Utiliza el LDP la recepcin

regular de los mensajes de protocolo para supervisar la salud de la sesin. A falta de cualquier

nueva informacin que necesita ser comunicada entre los compaeros, se envan mensajes de

actividad.

La asociacin entre una FEC y una etiqueta se anuncia a travs de mensajes de etiquetas:

mensajes de asignacin de etiquetas para la publicidad de nuevas etiquetas, la etiqueta retirar

mensajes para la retirada anunciada previamente de etiquetas, etc. La regla LDP fundamental

establece que LSR A que recibe una asignacin para la etiqueta L a la clase FEC F desde su LDP LSR

pares B utilizar etiqueta L para reenviar si y slo si B est en el camino ms corto IGP para el

destino F desde el punto de vista de una. Esto significa que LSPs establecen arriba a travs de LDP

sigue siempre el camino ms corto IGP y que los usos del LDP de la IGP para evitar bucles.

Relacin entre el PLD y el IGP

El hecho de que LDP se basa en la IGP para la funcin de enrutamiento tiene varias implicaciones:

1. Los proveedores de servicios lingsticos establecidos por el PLD siempre siguen el camino

ms corto IGP. Los caminos LSP se desplazan en la red cuando el camino IGP cambia, en

lugar de ser clavado a una ruta predefinida.

2. El alcance de LSPs establecidas-LDP es limitado al mbito de la IGP. Por lo tanto, LDP LSP

no puede atravesar los lmites del sistema autnomo. La necesidad de inter-AS LSPs, as

como la solucin propuesta por el IETF para establecerlas, se explica en el captulo

Ingeniera de Trfico de este libro (Captulo 5).

3. Durante reconvergencia, el trfico puede ser negro agujereado o bucle. La existencia de

bucles y la posibilidad de trfico agujero negro es un hecho de la vida para los IGPs

durante reconvergencia. Las mismas propiedades se heredan por LDP, en virtud de ello

confiar en el IGP para decisiones de enrutamiento. Vamos a discutir cmo tales lazos se

crean y cul es su impacto en la proteccin y restauracin en el captulo de este libro

(Captulo 3).

Hasta ahora hemos visto cmo MPLS utiliza etiquetas para el reenvo, pero cmo son los enlaces

entre las etiquetas y FECs distribuidos toda la red? Dado que la configuracin manual no es una

opcin, existe una clara necesidad de un protocolo para difundir esta informacin. Desde un punto

de vista prctico, hay dos opciones:

(c) Inventar un nuevo protocolo para la distribucin de las ligaduras de etiqueta o

(d) Ampliar un protocolo existente para llevar etiquetas, adems de la informacin de

enrutamiento. La cuestin de si se debe inventar un nuevo protocolo o extender una

existente es muy popular en el mundo MPLS, y se lo discutir en detalle en los captulos

posteriores. En este punto. En cuanto a la distribucin de las cadenas de las etiquetas, la

ingeniera comunidad invent un nuevo protocolo (LDP o distribucin de etiquetas Dos

protocolos de protocolo) y extendidos existentes (de RSVP, o de recursos Reserva

Protocolo, y BGP, o Border Gateway Protocol). Los formatos de paquetes y

funcionamiento bsico de estos protocolos se explican en detalle en muchos textos

introductorios [Doyle Kolon, Osborne Simha]. En vez de repetir esta informacin aqu,

vamos a examinar en lugar las propiedades de los diferentes protocolos y ver los

beneficios y limitaciones de cada uno de ellos.

1.3.2.1 LDP

LDP [RFC3036] es el resultado del Grupo de Trabajo MPLS [MPLS WG] en la IETF. A diferencia de

RSVP o BGP, que exista antes MPLS y se extendieron a hacer distribucin de etiquetas, LDP fue

especficamente diseado para distribuir etiquetas en la red. Desde el objetivo del LDP es la

etiqueta de distribucin, LDP no intenta realizar funciones de enrutamiento y se basa en una

puerta de enlace interior Protocol (IGP) para todas las decisiones relacionadas con el

enrutamiento. La especificacin original LDP se defini para la creacin de LSP para FECs que

representa una direccin IPv4 o IPv6. Esta es la funcionalidad que se describe en esta seccin. Las

extensiones de LDP utilizados para pseudowire y la sealizacin VPLS ser discutido los captulos.

LDP fue diseado con la finalidad para extenderse fcilmente. Toda la informacin intercambiada

en LDP se codifica como TLV (tipo-longitud-valor). El tipo y longitud estn en el inicio de la

codificacin, y su longitud se conoce de antemano. El tipo de informacin que identifica es

intercambiado y determina cmo el resto de la codificacin es para ser entendido. El valor se

intercambia la informacin real y la longitud es la longitud del campo de valor. TLV hacen que sea

fcil para: (a) aadir nuevas capacidades mediante la adicin de un nuevo tipo y (b) omitir

desconocido objetos al ignorar la cantidad de datos que se especifican en el campo de lon gitud.

Con los aos, se han aadido muchas nuevas capacidades para el protocolo Gracias a la

incorporacin de la extensin.

Operacin LDP es impulsado por el intercambio de mensajes entre pares. Pares potenciales,

tambin conocidos como los vecinos, son automticamente descubiertos a travs de mensajes de

saludo multidifusin UDP a un conocido puerto. El protocolo tambin permite el descubrimiento

de interlocutores remotos utilizando mensajes de hola dirigidos. Una vez que se descubre un

compaero potencial, un TCP se establece la conexin a la misma y una sesin LDP se establezca.

En sesin de tiempo de inicializacin, los interlocutores intercambian informacin sobre las

caractersticas y modo de funcionamiento que apoyan. Despus de la sesin de configuracin, los

interlocutores intercambian informacin con respecto a la unin entre etiquetas y FECs travs de

la conexin TCP. El uso de TCP garantiza la entrega fiable de la informacin y permite

incrementales actualizaciones, en lugar de actualizaciones peridicas. Utiliza el LDP la recepcin

regular de los mensajes de protocolo para supervisar la salud de la sesin. A falta de cualquier

nueva informacin que necesita ser comunicada entre los compaeros, se envan mensajes de

actividad.

La asociacin entre una FEC y una etiqueta se anuncia a travs de mensajes de etiquetas:

mensajes de asignacin de etiquetas para la publicidad de nuevas etiquetas, la etiqueta retirar

mensajes para la retirada anunciada previamente de etiquetas, etc. La regla LDP fundamental

establece que LSR A que recibe una asignacin para la etiqueta L a la clase FEC F desde su LDP LSR

pares B utilizar etiqueta L para reenviar si y slo si B est en el camino ms corto IGP para el

destino F desde el punto de vista de una. Esto significa que LSPs establecen arriba a travs de LDP

sigue siempre el camino ms corto IGP y que los usos del LDP de la IGP para evitar bucles.

Relacin entre el PLD y el IGP

El hecho de que LDP se basa en la IGP para la funcin de enrutamiento tiene varias implicaciones:

4. Los proveedores de servicios lingsticos establecidos por el PLD siempre siguen el camino

ms corto IGP. Los caminos LSP se desplazan en la red cuando el camino IGP cambia, en

lugar de ser clavado a una ruta predefinida.

5. El alcance de LSPs establecidas-LDP es limitado al mbito de la IGP. Por lo tanto, LDP LSP

no puede atravesar los lmites del sistema autnomo. La necesidad de inter-AS LSPs, as

como la solucin propuesta por el IETF para establecerlas, se explica en el captulo

Ingeniera de Trfico de este libro (Captulo 5).

6. Durante reconvergencia, el trfico puede ser negro agujereado o bucle. La existencia de

bucles y la posibilidad de trfico agujero negro es un hecho de la vida para los IGPs

durante reconvergencia. Las mismas propiedades se heredan por LDP, en virtud de ello

confiar en el IGP para decisiones de enrutamiento. Vamos a discutir cmo tales lazos se

crean y cul es su impacto en la proteccin y restauracin en el captulo de este libro

(Captulo 3).

1.3.2 Mecanismos de plano de control

Hasta el momento hemos visto como MPLS utiliza etiquetas para el reenvio, pero como son los

enlaces entre etiquetas y FECS distribuidos a travs de la red? Dado que el manual de configuracin

no es una opcin, claramente hay una necesidad de un protocolo para diseminar esa informacin.

Desde un punto de vista prctica hay dos opciones: (a) inventa un nuevo protocolo para distribuir

enlaces de etiquetas o (b) extender un protocolo existente para llevar las etiquetas adicionalmente

a la informacin de ruteo.

La incgnita de inventar un nuevo protocolo o extender uno existente es muy popular en el mundo

MPLS, y se discutir en detalle en los siguientes captulos. En este punto, es suficiente decir que

cuando se presenta la incgnita, el resultado es usualmente que los dos enfoques son seguidos.

Respecto a la distribucin de lazos de etiquetas, la comunidad de ingenieros invento un nuevo

protocolo (LDP, label distribution protocol) y extendi dos protocolos existentes (RSVP y BGP). Los

formatos de paquetes y operaciones bsicas de estos protocolos son explicados en detalle en varios

textos introductorios (Doyle Kolon, Osborne Simha).

En lugar de repetir esta informacin aqu, se examinar las propiedades de diferentes protocolos y

ver los beneficios y limitaciones de cada uno.

1.3.2.1 LDP

LDP (RFC 3036) es el resultado del grupo de trabajo MPLS en la IETF. A diferencia de RSVP o BGP,

que existieron antes de MPLS y fueron extendidos para la distribucin de etiquetas, LD fue

especficamente diseado para distribuir etiquetas en la red. Ya que la meta de LDP es la distribucin

de etiquetas, LDP no intenta realizar ninguna funcin de enrutamiento y confa en el protocolo IGP

para todas las decisiones relacionadas a ruteo. La especificacin original de LDP fue definida para

establecer LSPs para FECs representado una direccion IPv4 o IPv6. Esta es la funcionalidad descrita

en esta seccin. La extensin de LDP usada para pseudo cableado y sealizacin de VPLS ser

discutido en los captulos apropiados.

LDP fue diseado con extensibilidad. Toda la informacin intercambiada en LDP es codificada como

TLV (type, length, value). El tipo y longitud estn al comienzo de la codificacin, y la longitud es

conocida en adelanto. El tipo identifica cual informacin es intercambiada y determina como el resto

de codificacin debe ser interpretado. El valor es en realidad la informacin intercambiada y la

longitud es la longitud del campo valor. TLV facilita: (a) aadir nuevas funcionalidades aadiendo un

nuevo tipo y (b) saltar objetos desconocidos ignorando la cantidad de datos especificado en el

campo de longitud.

A lo largo de los aos, varias nuevas funcionalidades fueron aadidas al protocolo gracias a su

extensibilidad incorporada.

La operacin de LDP es realizada mediante intercambio de mensajes entre pares. Pares potenciales,

tambin conocidos como vecinos, son automticamente descubiertos mediante mensajes hello de

tipo multicast a un puerto UDP bien conocido. El protocolo tambien permite descubrir a pares

remotos usando mensajes hello con un objetivo. Una vez que un par potencial es descubierto, se

establece una conexin TCP y se inicia una sesin LDP. Al tiempo de inicializacin de sesin, los pares

intercambian informacin acerca de los lazos entre etiquetas y FECs sobre la conexin TCP. El uso

de TCP asegura una entrega confiable de la informacin y permite actualizaciones de incremento en

lugar de actualizaciones peridicas. LDP utiliza la recepcin de mensajes de protocolo para

monitorear la sesin. Si hay ausencia de nueva informacin que necesita ser comunicada entre los

pares, se envan mensajes de tipo keepalive.

La asociacin entre FECs y una etiqueta es publicada mediante mensajes de etiqueta: mensajes de

mapeo de etiqueta para informar sobre nuevas etiquetas, mensajes de retiro de etiqueta para

retirar etiquetas previamente establecidas, etc. La regla fundamental de LDP dicta que un LSR A

recibe un mapeo de la etiqueta L para FEC F desde su LDP par, LSR B utilizar la etiqueta L para

conmutar si y solamente si B est en el camino ms corto de IGP para el destino F desde el punto de

vista de A. Esto significa que LSPs que se establecen via LDP siguen siempre el camino ms corto de

IGP y que LDP usa IGP para evitar lazos de enrutamiento.

Relacin entre LDP e IGP

El hecho de que LDP utilize IGP para la funcin de ruteo tiene varias implicaciones:

1. Los LSPs establecidos por LDP siempre siguen el camino ms corto IGP. Los caminos LSP cambian

en la red cuanto el camino de IGP cambia, en lugar de estar asignados a un camino predeterminado.

2. El alcance de los LSPs establecidos por LDP est limitado al alcance de IGP. De tal manera, LDP

LSPs no pueden atravesar lmites de sistemas autnomos(AS). La necesidad de LSPs inter-AS, as

como la solucin propuesta por la IETF para ser establecidos, se explica en el captulo de Ingeniera

de trfico inter dominio.

3. Durante la reconvergencia, el trfico puede ser perdido o caer en un lazo. La existencia de lazos y

la posibilidad de prdida es un hecho innegable durante la reconvergencia de IGPs. Las mismas

propiedades son heredadas por LDP, por confiar en IGP para el ruteo. Se discutir como dichos lazos

son creados y el impacto en el captulo de proteccin y restauracin.

4. El tiempo de convergencia IGP representa una medida inferior del tiempo de convergencia LDP.

Suponiendo que IGP implementa mecanismos inteligentes de rpida convergencia la prdida de

trfico est en el intervalo de 1-2 segundos, rdenes de mayor magnitud que el tiempo rpido de

redireccionamiento de RSVP. El IETF est trabajando actualmente en la adicin de capacidades de

clculo rpido de la ruta a la LDP. Esto se discute con ms detalle en el captulo de Proteccin y

Restauracin de este libro (Captulo 3).

5. La prdida de sincronizacin entre IGP y LDP puede resultar en la prdida de trfico. Como

siempre, para situaciones donde los dos protocolos necesariamente operan en tndem, hay un

potencial para condiciones de carrera. Echemos un vistazo ms de cerca a una condicin de

carrera causado por la prdida de sincronizacin entre IGP y LDP. En la topologa diamantada en la

Figura 1.4, LSR A asigna un vnculo para la FEC A de este loopback. Para empezar, todos los enlaces

tienen la misma mtrica, y el enlace C-D no existe en la topologa. Desde el punto de vista del

punto D, el LSP para FEC A sigue el camino D-B-A. En un momento posterior el enlace C-D se aade

a la topologa con una mtrica que es mejor que la mtrica de enlace B-D, haciendo que el camino

ms corto IGP desde el punto de vista del punto D es D-C-A. Supongamos que la IGP reacciona ms

rpido que LDP. Tan pronto como D se entera del cambio de enrutamiento, deja de utilizar el

enlace que recibi de B, rompiendo as el LSP. El LSP se queda abajo hasta que una unin de FEC A

es recibido en la sesin LDP C-D. Esto puede llevar un tiempo, dependiendo de qu tan rpido el

establecimiento de la sesin se lleva a cabo. La situacin descrita aqu es particularmente poco

atractiva, ya que existe una ruta alternativa en la topologa y podra haber sido utilizado hasta que

la sesin LDP levante el enlace C-D.

El ejemplo anterior muestra una prdida de sincronizacin causada por el hecho de que la sesin

LDP en el nuevo enlace viene despus de la sesin IGP. Esta no es la nica manera en la que la

prdida de sincronizacin puede ocurrir: olvidar habilitar LDP en la nueva interfaz, configuracin

de la sesin de autenticacin de LDP, la creacin de filtros de cortafuegos que bloquean el trfico

LDP o cualquier otro evento que hara que IGP tuviera un enlace en cuenta, pero causara que LDP

no utilizara el enlace, tienen el mismo efecto. Una solucin a este problema es enlazar (a travs de

la configuracin) la mtrica IGP para un enlace concreto a la existencia de una sesin LDP en el

enlace [LDP-IGP-SYNC]. Cuando la sesin LDP est abajo, la mtrica IGP advertido para el enlace es

muy alta. Por lo tanto, si una ruta alternativa est disponible, se pueden usar las etiquetas LDP en

ese camino. Esto se discute en ms detalle en el captulo de Gestin de MPLS de este libro

(Captulo 12). Hasta ahora hemos visto las implicaciones de tener LDP dependen de IGP para la

funcin de enrutamiento. A continuacin, vamos a echar un vistazo a la seleccin de modos de

distribucin y retencin de etiquetas hechas por las implementaciones de LDP comunes.

Retencin de etiquetas y los modos de distribucin de etiquetas

Modo de distribucin de etiquetas - que asigna las etiquetas? la clave funcin del PLD es distribuir enlaces entre etiquetas y FEC . El objetivo es construir una tabla de reenvo que contiene un mapeo entre una etiqueta de entrada y una etiqueta de salida. trfico procedente en la LSR etiquetado con la etiqueta entrante se desva etiquetado con la etiqueta de salida . Cuando la construccin de la tabla de reenvo, el pregunta es si se debe utilizar la etiqueta recogido localmente como el entrante o la etiqueta de salida. La arquitectura MPLS [ RFC3031 ] utiliza aguas abajo asignacin de etiquetas , lo que significa que el router espera recibir el trfico con la etiqueta que se recogi a nivel local. Por ejemplo, si LSR A recibe etiqueta L1 para FEC F y anuncia etiqueta L2 para ello, entonces se espera que el trfico destinado a la clase FEC F a venir marcada con etiqueta L2. Al reenviar e l trfico de la clase FEC F , LSR Una etiqueta en el trfico con la etiqueta L1 . El trfico fluye en la direccin opuesta de la distribucin de etiquetas. El mtodo se llama aguas abajo porque la etiqueta que se asigna al trfico en el punto P en el red fue realmente elegido por un router que es un salto ms abajo en la direccin del flujo de trfico (aguas abajo) de P. La siguiente pregunta es: debe etiquetas anunciarse slo a aquellos pidiendo para ellos ( la etiqueta de distribucin on-demand ) o para todo el mundo ( distribucin de etiquetas no solicitado ) ? Ya hemos visto que en demanda de distribucin de etiquetas tiene la propiedad indeseable blackholed hasta que la solicitud de la etiqueta es satisfecho. Para esta razn, la mayora de las implementaciones utilizan la etiqueta no solicitado modo de distribucin. Desde LDP utiliza la asignacin de etiquetas posterior, el modo de distribucin de etiquetas que normalmente se conoce como aguas abajo no solicitado. Retencin Liberal, junto con los anuncios de la etiqueta no solicitados, asegura que las etiquetas recibidas de los pares estn fcilmente disponibles. Este es importante para el manejo de los cambios de itinerario de una manera transparente. Para entender mejor esto, echemos un vistazo a LSR A, que recibe dos anuncios de etiqueta no solicitadas con FEC F : uno con la etiqueta L1 de pares B y uno con la etiqueta L2 a partir de pares C. LSR A mantiene ambas etiquetas , ya que est haciendo la retencin liberal. Suponiendo que la ruta IGP para FEC F seala al par B , LSR instala la etiqueta L1 en su tabla de reenvo. Si en algn momento despus de los cambios y de rutas IGP comienza sealando a pares C , todo lo que LSR A tiene que hacer es cambiar su tabla de reenvo a utilizar la etiqueta L2 .

El control sobre la configuracin LSP El nico propsito de la distribucin de las consolidaciones entre las etiquetas y FECs es establecer rutas de etiquetas conmutadas en la red . Hasta el momento tenemos discutido muchas propiedades interesantes del PLD pero an no respondi a dos preguntas fundamentales: ( a) que FEC para anunciar un vinculante

para y ( b ) cundo se anunciar esta unin . La eleccin de FEC se deriva de la LSP que debe ser configurado en la red . Es independiente del protocolo LDP y por lo tanto la especificacin del PLD no se pronuncia sobre este tema . Todos los vendedores permiten control sobre la eleccin de FEC travs de la configuracin , pero la el comportamiento en ausencia de una configuracin definida por el usuario es diferente por diferentes proveedores. Algunos anuncian un enlace para cada prefijo en su tabla de enrutamiento , mientras que otros slo anuncian una unin para el FEC correspondiente a la direccin de bucle de retorno de la LSR . El resultado en trminos del nmero de proveedores de servicios lingsticos que se instalan y de los destinos accesible a travs de estos LSP es bastante diferente. No hay bien o mal decisin aqu , ya que diferentes implementaciones pueden tener diferente restricciones. Sin embargo, a partir de una red de operaciones de punto de vista, es una mala idea permitir LDP para publicitar enlaces para FECs esa voluntad no se utilizarn para el reenvo. La informacin adicional de unin y LSP consume recursos en la red y hace que la solucin de problemas extremadamente difcil. La eleccin de FEC determina qu LSP se establezcan. la decisin cundo se anunciar la etiqueta de unin determina quin tiene el control sobre la configuracin de la LSP. La especificacin LDP permite dos modos de operacin: control y el control independiente ordenado. Dado que no todos proveedores implementan el mismo modo, vamos a echar un vistazo ms de cerca a la dos opciones y sus propiedades, por referencia a la figura 1.5 . para el efectos de esta discusin , asumen que no existe vnculo IF5 . Este enlace se utiliza para una discusin ms adelante en esta seccin.

El control ordenado. Bajo control ordenado, egreso iniciados LSR PE1 la configuracin LSP por etiqueta asignar L1 a la FEC correspondiente a su loopback direccin PE1 y publicidad esta asignacin a sus pares A. Tras la recepcin de la asignacin de la etiqueta, A evala si es PE1 en el camino ms corto IGP para que FEC. Puesto que la comprobacin es correcta Una etiqueta cesionarios L2 para FEC PE1, instala el reenvo intercambio estado etiquetas L2 y L1 y anuncia una unin de etiqueta L2 y FEC PE1 a sus pares B, que va a hacer el procesamiento similar. Si el cheque no es xito, A no anunciar la FEC ms. en este la moda, las ganancias de configuracin LSP en una forma ordenada desde la salida a la entrada . Cada LSR consulta la IGP para dos decisiones: (a) si para anunciar una asignacin para un FEC y ( b ) si se utiliza una etiqueta para el reenvo

LSR C notifica que el enrutamiento ah cambiado y la etiqueta de salida se instala en la tabla de

reenvio para FEC PE1 ya no es vlido y elimina el estado de reenvio para FEC PE1. PE2 no cambia su

estado de envio ya que desde su punto de vista el mejor camino para PE1 sigue siendo a travs de

C. El efecto neto es que la LSP para PE1 se rompe en el punto C, pero PE2 es conscientes del fracaso.

Se continuar enviando trfico etiquetado en

este LSP y el trfico ser dado de baja en C. Este tipo de falla en silencio es muy problemtica en un

entorno VPN, como veremos en captulos posteriores. Una solucin a este problema es el esquema

descrito en [LDP-IGP-SYNC], en la cual la mtrica IGP para un enlace esta dada, un alto valor si LDP

no est en pleno funcionamiento a travs del enlace. Como se ha descrito anteriormente, este

esquema es tambin una solucin a las condiciones de carrera entre PLD y el IGP.

Las implementaciones de apoyo de cada uno de los dos modos de operacin

puede ser y se despliegan juntos en la misma red [LDP-OP]. La clave para la interoperabilidad es el

hecho de que LSRs no asumen nada relacionado con el comportamiento de sus compaeros,

excepto instalacin consistente del estado de envo siguiendo el camino IGP. Ahora que hemos

hablado de la manera en que las etiquetas del PLD se distribuyen, veamos un ejemplo de un LDP

LSP. La figura 1.6 ilustra el

hecho de que LDP forma un "rbol invertido" enraizado en cada punto de salida en

la red a travs de los mecanismos ya descritos. La figura muestra la mtrica IGP en cada enlace y la

seal-LDP

LSP enraizada en D. Las flechas muestran la direccin del flujo de datos. Se puede observar que el

camino LSP sigue la mejor ruta segn lo determinado por el IGP. En cualquier enlace en particular,

la etiqueta utilizada para llegar a un router de destino en particular es la misma,

independientemente del origen del paquete.

As, por ejemplo, en el enlace F-C todos los paquetes cuyo destino es D tienen un valor de la etiqueta

de 27, independientemente de si se originaron en G o A o F. Tambin, si el espacio por plataforma

de etiqueta se utiliza, el router C (para ejemplo) anuncia el mismo valor de la etiqueta con el fin de

llegar a D a todos sus vecinos, por lo que todo el trfico que pasa a travs de C para llegar a D tiene

el mismo valor de la etiqueta en todos los enlaces en C. por lo tanto el trfico de B a D tambin tiene

un valor de etiqueta de 27 en el enlace B-C. Ntese que en el ejemplo, se utiliza el penltimo salto,

por lo que D anuncia un valor de etiqueta de 3 a sus

vecinos. El diagrama slo muestra el rbol con raz en D. En realidad, habra mltiples rboles

superpuestos, cada uno con raz en un router diferente en la red. Como resultado, en cualquier

enlace en particular varias etiquetas pueden estar en uso en caso de mltiples routers son accesible

a travs de ese enlace.

Al igual que con los IGP, por lo general las implementaciones del LDP instalan mltiples entradas de

la tabla de reenvo (ECMP) en situaciones de igual costo. Por ejemplo, en la Figura 1.6, si la mtrica

entre E y D eran 5 en lugar de 10, habra dos rutas de igual coste de F a D, F-E-D y F-C-D. Por lo tanto

F instala dos entradas de reenvo para D, uno correspondiente a cada ruta. El trfico llega a F por D

se balancea la carga sobre los dos caminos.

Propiedades de la llave LDP

Aqu est un resumen de las propiedades de la llave LDP:

Deteccin automtica de pares. LDP utiliza mensajes de descubrimiento para

encontrar LSRs pares. Esto proporciona dos ventajas importantes:

La facilidad de configuracin. El operador no necesita configurar cada par individual. La

adicin de un nuevo LSR en la red requiere la configuracin de la nueva LSR, pero no de

cualquiera de los otros LSRs en la red (en contraste con RSVP).El descubrimiento automtico

integrado en el protocolo LDP es una de las razones ms convincentes para recoger LDP

como el protocolo de distribucin de etiquetas en las redes donde no se requiere la

ingeniera de trfico.

Mantenimiento de la sesin.- La cantidad de estado de sesin de un LSR debe mantenerse

proporcional al nmero de vecinos. En la ausencia de pares especficos, este nmero es constante, independientemente del tamao de la red.

Falta 21-22

Transporte confiable. LDP utiliza TCP como protocolo de transporte para todo excepto para los mensajes de descubrimiento. Una vez que se anuncia, la informacin no necesita ser refrescada. Los mensajes de actividad se envan peridicamente para mantenimiento de la sesin, pero su nmero es proporcional al nmero de sesiones, no a la cantidad de inf ormacin que se intercambi durante la sesin. Diseo Extensible. LDP utiliza TLV para pasar informacin. Dependencia de la IGP.1 LDP se basa en el protocolo IGP para las decisiones relacionadas con el enrutamiento. LDP-establecidos LSPs siguen la ruta ms corta y son influenciados por cambios en el enrutamiento. Durante los perodos de convergencia de redes, LDP LSP se ven afectados, y el trfico puede entrar en bucle.

Retencin de etiquetas Liberal y etiquetas de distribucin intermedias no solicitadas. Las etiquetas se anuncian a todos los compaeros y son conservados incluso si no se utilizan activamente para el reenvo. As LDP reacciona rpidamente a cambios en el enrutamiento IGP. RSVP Otro esquema de distribucin de etiquetas para el transporte LSP, se basa en el Protocolo de reserva de recursos (RSVP).RSVP fue inventado antes que MPLS entre en funcionamiento, y se concibi originalmente como un esquema para crear reservas de ancho de banda para los flujos de trfico individual en las redes (por ejemplo, una sesin de vdeo telefona entre un par particular y un hosts) como parte del modelo llamado 'int -serv'. RSVP incluye mecanismos para reservar ancho de banda a lo largo de cada salto de una red para una sesin de extremo a extremo. Sin embargo, la aplicacin int -serv original de RSVP ha cado en desgracia debido a preocupaciones por su escalabilidad: el nmero de sesiones de host de extremo a extremo que pasan a travs de una red de proveedores de servicio sera muy grande, y dentro de l a red, no sera deseable para los routers tener que crear, mantener y eliminar el estado as como las sesiones que vienen van. En el contexto de MPLS, RSVP se ha ampliado para permitir que sea utilizado para la creacin y mantenimiento de LSPs y crear reservas de ancho de banda asociados [RFC 3209]. Cuando se utiliza en este contexto, el nmero de sesiones de RSVP en la red es mucho menor que en el caso del modelo int -serv debido a la forma en la que el trfico se agrega en un LSP. Un nico LSP slo requiere una sesin RSVP, todava puede llevar todo el trfico entre una entrada particular y salida del router, que contiene muchos flujos de extremo a extremo. Un LSP RSVP- sealado tiene la propiedad de que su camino no sigue necesariamente el camino que sera establecido por el IGP. RSVP, en su forma extendida, tiene propiedades de enrutamiento explcitas en ese router, la entrada puede especificar la ruta completa de extremo a extremo que el LSP debe seguir, o puede especificar que el LSP debe pasar por de terminados nodos de trnsito. Aqu estn algunas consecuencias de las propiedades de enrutamiento explcitas de RSVP:

1. El camino no sigue necesariamente la ruta IGP. La ruta puede ser calculada para cumplir con diferentes limitaciones que no pueden ser tenidos en cuenta cuando se calculan las rutas IGP. Como tal, los LSP RSVP- sealado son un componente clave de la ingeniera de trfico basada en MPLS, lo que permite la administrador de la red controlar la ruta tomada por el trfico determinado entre un par de puntos finales mediante la colocacin de la LSP.

2. La ruta puede ser calculada en lnea por el router o utilizando un instrumento de computo de clculo de ruta cuando no es en lnea. En el primer caso, tpicamente solo el router de entrada tiene que ser consciente de todas las restricciones que se aplicar a la LSP, Por otra parte, el uso de las rutas explicitas elimina la necesidad de que todos los routers, a lo largo del camino, mantengan una base de datos de informacin consistente donde conste las rutas y un algoritmo de clculo de ruta.

3. La ruta de acceso no se limita a un nico dominio IGP. Mientras se especifica una ruta de alguna manera, RSVP no se limita a un nico dominio IGP (a diferencia de LDP). La restriccin de un solo dominio IGP no entran a ser calculadas en lnea, como se ver en el captulo de Ingeniera de Trfico de este libro (Captulo 2)

4. Un LSP se puede sealizar de una manera tal que su camino slo puede ser cambiado por el extremo de la cabeza. Esto est en contraste con LDP, donde cada LSR actualiza su estado de reenvo de forma independiente de todos los dems LSRs ya que rastrea el

estado IGP. Esta propiedad es muy importante en el contexto de los esquemas de proteccin del trfico tales como Fast Reroute, discutidos en detalle en la proteccin y restauracin captulo de este libro (Captulo 3).

RSVP requiere un intercambio peridico de mensajes una vez que un LSP es establecido con el fin

de mantener ('refrescar') su estado. Esto puede ser logrado por el envo peridico de mensajes de

Path y Resv para cada LSP activo. Si un router no recibe un cierto nmero consecutivos de

mensajes Path o Resv para un LSP particular, se considera ya no es necesario y elimina todos los

estados (como reenvo de entradas y reservas de ancho de banda) que pertenecen al LSP. La

sobrecarga de procesamiento de dicho sistema puede llegar a ser una preocupacin para un

router que de mantenimiento a un nmero muy grande de LSP. Para hacer frente a esto, el

'Actualizar Extensiones de reduccin' ha sido concebido para reducir esta sobrecarga. Estos

incluyen un Resumen de Actualizaciones de Extensin que permite sesiones de RSVP (y por tanto

mltiples LSP) que han sido refrescados por un solo mensaje enviado entre vecinos de RSVP por

intervalo de actualizacin [RFC2961].

RSVP tiene un mecanismo opcional de deteccin de fallas de un nodo, en los mensajes hola que

se envan peridicamente entre los vecinos de RSVP.

Sin este mecanismo, un nodo slo podra llegar a ser consciente del fallo de un vecino a travs de l

tiempo de espera de las sesiones de RSVP, que puede tomar un tiempo relativamente largo.

Se debe tener en cuenta que no existe el concepto de ECMP en RSVP como lo hay en LDP. Un LSP

particular, sigue a un solo camino desde la entrada a la salida.

Si, al realizar el clculo del camino, el Router de ingreso encuentra que hay varias rutas potenciales

para un LSP que tienen igual mrito, elige una de esas rutas para el LSP y seales para su creacin

a travs de RSVP. Por lo tanto, una vez que el trfico se ha entrado en una sealizado RSVP-LSP, no

hay divisin y fusin de trfico como ocurre a veces en el caso LDP.

En algunos casos, una red puede tener slo un puado de RSVP-sealado LSP, como una forma

tctica de controlar los flujos de trfico particular. En esas situaciones, LSP RSVP-sealado se

creara entre ciertos pares de puntos finales para lograr este objetivo. En otras redes, la razn para

el despliegue de RSVP sealizado - LSPs pueden estar en orden de hacer uso de

redireccionamiento rpido, en cuyo caso el administrador puede optar por malla plenamente las

empresas pblicas en la red con LSP RSVP-sealado.

A modo de resumen, aqu estn las propiedades clave de RSVP:

Encaminamiento explcito. El LER de entrada tiene el control sobre el camino tomado por

el LSP, ya sea mediante la especificacin de la ruta completa o especificando nodos

particulares que la LSP debe atravesar. Como consecuencia RSVP se presta para la

ingeniera de trfico y proteccin del trfico en esquemas que operan

independientemente de, y ms rpido que, IGP.

Se requiere el intercambio de mensajes peridica para renovar el estado de un LSP,

aunque el Estado de Actualizaciones RSVP reducir esta sobrecarga.

La cantidad de estado de sesin en un nodo es proporcional al nmero de LSP que

atraviesan el nodo. Esto tiende a crecer a medida que la red crece (suponiendo un alto grado de mallado de RSVPsignaledLSP).

Comparacion entre RSVP y LDP

Una pregunta frecuente es si LDP o RSVP es el mejor protocolo a utilizar en un despliegue.

Comparemos los dos protocolos con respecto a los factores que afectan a la eleccin de cul

utilizar:

1. Facilidad de configuracin:

a) La configuracin inicial. LDP tiene la ventaja de que es fcil configurar, slo requiere una

lnea de configuracin de algunas implementaciones, para permitir que el protocolo se

ejecute en una interfaz particular. RSVP, por otra parte, requiere configuracin explcita de

los proveedores de servicios lingsticos en el router de entrada. Cada router debe

conocer todos los dems routers a los que se debe establecer LSP.

b) Configuracin incremental cuando los nuevos dispositivos de borde son aadidos. Para

PLD, slo el nuevo dispositivo debe ser configurado. Para RSVP, aadiendo un nuevo

router al borde significa configuracin LSP para todos los routers existentes, lo que requiere cambios de configuracin en todos los dems routers de borde en la red.

En este momento hay tendencia a reducir el esfuerzo de configuracin cuando se usa RSVP. Un

esquema es una capacidad de mallado automtico, donde cada router de borde en la red de forma

automtica crea un LSP RSVP-sealado a los otros routers de borde en la red. Otra es una

capacidad autobandwidth, donde la reserva de ancho de banda para un LSP cambia de acuerdo

con el volumen de trfico que usando LSP. Se utiliza en combinacin, el esfuerzo de configuracin

no sera muy diferente al asociado con LDP. Esos planes no pueden ayudar en todos los casos, sin

embargo, por ejemplo cuando cada LSP tiene limitaciones particulares asociados a ella o requiere

una reserva de ancho de banda fijo en lugar de uno que vara dinmicamente.

RSVP requiere un intercambio peridico de mensajes una vez establecido un LSP para mantener

('Refresh') su estado. Esto puede lograrse enviando mensajes Path y Resv peridicamente para cada

LSP activo. Si un router no recibe un determinado nmero de mensajes Resv o Path consecutivos

para un LSP particular, se considera el LSP como ya no necesario y elimina todos los estados (tales

como entradas de reenvo y reservas de ancho de banda) pertenecientes a dicho LSP. La sobrecarga

de procesamiento de un sistema de este tipo puede convertirse en una preocupacin de escala para

un router que mantiene de un gran nmero de LSPs.

Para solucionar este problema, la 'reduccin de extensiones de actualizacin' a RSVP fueron ideadas

para reducir esta carga. Estos incluyen un Resumen Extensin Actualizacin que permite mltiples

sesiones RSVP (y por ende mltiples LSP) tener su estado renovados por un nico mensaje enviado

entre vecinos RSVP para el intervalo de actualizacin RFC2961.

RSVP tiene un mecanismo opcional de deteccin de fallo del nodo, en cual los mensajes Saludo se

envan peridicamente entre los vecinos RSVP. Sin este mecanismo, un nodo slo podra ser

consciente del fracaso de un vecino a travs del tiempo de espera de RSVP sesiones, lo que puede

tardar un tiempo relativamente largo.

Tenga en cuenta que no hay ningn concepto de ECMP en RSVP de LDP. Un LSP particular sigue un

solo camino de entrada para salir. Si, al realizar el clculo de ruta, el router de entrada descubre que

hay varias rutas posibles para un LSP que tienen iguales mritos, elige uno de los caminos para las

seales de su creacin mediante RSVP y LSP. Por lo tanto, una vez que el trfico ha introducido un

LSP RSVP-sealado, no hay ninguna divisin y fusin de trfico como a veces ocurre en el caso del

PLD. En algunos casos, una red puede tener un slo puado de LSPs RSVP-sealados, como una

forma tctica de controlar los flujos de trfico en particulares Hot-Stops en la red. En esas

situaciones, se crearan LSP RSVP-sealado entre determinados pares de terminales para lograr este

objetivo.

En otras redes, la razn para el despliegue de LSP RSVP-sealado podra ser el fin de hacer uso de

redireccionamiento rpido, en cuyo caso el administrador puede optar por malla completa de PEs

en la red con LSP RSVP-sealado. A modo de resumen, aqu estn las propiedades clave de RSVP:

Enrutamiento Explcito. El LER de entrada tiene el control sobre el camino tomado por el

LSP, ya sea mediante la especificacin de la ruta completa o especificando nodos

particulares que la LSP debe pasar a travs. Como consecuencia, RSVP se presta a esquemas

de ingeniera de trfico y la proteccin del trfico que operan independientemente de, y

ms rpido que, el IGP.

Se requiere el intercambio de mensajes peridico para renovar el estado de un LSP, aunque

las reducciones de actualizacin de RSVP reducen esta sobrecarga.

1.3.2.3 Comparacin RSVP y LDP

Una pregunta frecuente es si LDP o RSVP es el mejor protocolo para utilizar en un despliegue.

Comparemos los dos protocolos con respecto a los factores que afectan la eleccin de cul utilizar:

1. Facilidad de configuracin:

a. La configuracin inicial. LDP tiene la ventaja de que es fcil de configurar, slo

requiere una lnea de configuracin en algunas implementaciones, para permitir

que el protocolo se ejecute en una interfaz particular. RSVP, por otra parte, requiere

configuracin explcita de los LSPs en el router de entrada. Cada router debe

conocer todos los dems routers a los que se debe establecer LSP.

b. Configuracin Incremental cuando se aaden nuevos dispositivos de borde. Para

PLD, slo el nuevo dispositivo debe ser configurado. Para RSVP, aadiendo un nuevo

router al borde significa la configuracin LSP es la misma de todos los routers

existentes, lo que podra requerir cambios de configuracin en todos los dems

routers de borde de la red.

Actualmente hay movimientos para reducir el esfuerzo de configuracin cuando se utiliza RSVP. Un

esquema es una capacidad de mallado automtico, donde cada router de borde en la red crea

automticamente un LSP RSVP-sealado a los otros routers de borde de la red. Otra es una

capacidad de ancho de banda automtico, donde la reserva de ancho de banda para un LSP cambia

de acuerdo con el volumen de trfico que usa LSP. Utilizado en combinacin, el esfuerzo de

configuracin no sera muy diferente a la asociada con LDP. Esos planes no pueden ayudar en todos

los casos, sin embargo, por ejemplo, cuando cada LSP tiene limitaciones particulares asociadas con

l o requiere una reserva de ancho de banda fijo en lugar de uno que vara dinmicamente.

Esto podra ser una gran reduccin si la relacin de Y a X es grande. Por ejemplo, considere una red que cuenta con 30 POPs, cada uno con dos routers de ncleo -frente y cinco routers de frontera. En el caso en que los routers de borde estn en full mesh con LSP RSVP-sealado, habra 22 350 (ie150 149) LSP RSVP-sealado en la red. En el caso en el que slo los dos routers de ncleo con orientacin en cada PoP estn plenamente en malla, habra un total de 3480 (es decir, 60 58) LSP RSVP-sealado en la red. Esto es casi un orden de magnitud menor que en el caso de malla completa. El menor nmero de LSP significa una carga ms ligera en los protocolos y los routers. Esto, en s mismo, es slo consecuencia prctica si la carga en el caso del router de borde totalmente mallado es insosteniblemente alto. Ms importante an, un menor nmero de LSP significa ms fcil aprovisionamiento y la gestin desde el punto de vista del operador. La LDP ms de RSVP de proceso se ilustra en la Figura 1.8, que muestra una seccin transversal a travs del borde y el ncleo de una red. Routers A, B y C estn dentro del mismo PoP. Routers F, G y H estn dentro de otro PoP. D y E son routers de ncleo. LDP se utiliza dentro de los POP. En la red, los routers de ncleo con orientacin en los POP son plenamente en malla con LSP RSVP-sealado. Por lo tanto hay un par de LSP RSVP-sealado entre C y F (uno en cada direccin). Adems, no estn dirigidas sesiones LDP entre los routers de ncleo con orientacin en cada PoP, es decir, entre C y F en el diagrama. La sesin LDP dirigida permite a C y F intercambiar directamente las etiquetas de los FECs asociados con los routers de frontera en sus respectivos puntos de presencia. Por ejemplo, C aprende de la etiqueta de F para utilizarla y reenviar el trfico a H. Routers D y E no estn involucrados en el proceso de sealizacin LDP y no guarde etiquetas del PLD.

Vamos a considerar el transporte de los paquetes que llegan a la red en el router A y salen de la red en el router H. La operacin plano de reenvo es de la siguiente forma: ingreso Router A empuja una etiqueta que se aprende a travs de LDP. En el ejemplo, el valor de la etiqueta es L1, y es la etiqueta asociada con H. Router B intercambia la etiqueta para uno que tiene el valor L2. Router C es el router de ingreso para la seal RSVP del LSP a travs del ncleo. C intercambia la etiqueta existente L2 para un valor de etiqueta L3 que tuvo conocimiento a travs de la sesin LDP apuntada con F. Adems, se empuja al paquete una etiqueta de valor L5 aprendi a travs de RSVP. Por lo tanto, en este punto, la pila de etiquetas consta de una etiqueta exterior del valor L5 y una etiqueta interna del valor L3. Los routers de core D y E slo estn al tanto de la LSP RSVP-sealado y por lo tanto slo se llevan a cabo operaciones en la etiqueta exterior. D intercambia la etiqueta ms externa de valor L5 para una etiqueta que tiene valor L6. Tenga en cuenta que la etiqueta que tiene valor L3 subyacente se deja intacto. Si PHP est en uso, en el router E aparece la etiqueta aprendida a travs de RSVP, exponiendo as a la etiqueta L3, que se enter a travs de LDP. Router F intercambia la etiqueta LDP para uno que tiene valor L4. Si PHP est en uso, en el router G aparece la etiqueta, la exposicin de la cabecera del paquete subyacente. Esto podra ser una cabecera IP o podra ser otra cabecera MPLS, por ejemplo, una etiqueta de VPN. En los casos donde se requieren las propiedades de RSVP de borde a borde, el LDP anteriormente sobre el esquema de RSVP no es adecuado. Sin embargo, en el caso de redes muy grandes, puede no ser factible, utilizar full mesh para todos los routers de borde con LSPs RSVPsignaled debido a la cantidad resultante del estado de RSVP en el ncleo de la red. El concepto de jerarqua LSP [LSP HIER] se introdujo para resolver este problema. En este esquema, una capa de routers estn en full mesh con LSP RSVP-sealado.

MPLS

El concepto de jerarqua de LSP se ilustra en la Figura 1.9. el diagrama muestra seis PEs, tres cada

dos puntos de presencia PoPs. P1 es un enrutador core-facing en un PoP y P3 es un router core-

facing en otro PoP. El diagrama muestra un LSP RSVP-sealado entre P1 y P3. Usando la Jerarqua

LSP, LSPs de borde a borde entre los routers PE en los dos PoPs se pueden anidar en el ncleo LSP

entre P1 y P3. Por ejemplo, hay un LSP entre PE1 y PE4, y otro entre PE2 y PE5 y as

sucesivamente. Sin embargo, P2 en el ncleo de la red y no conoce de la existencia de estos LSPs y

slo participa en la mantenimiento del LSP de ncleo. Esto es porque los mensajes RSVP asociados

con los LSPs de borde a borde pasan directamente entre P1 y P3 sin ser procesada por el plano de

control de P2.

Nivel de distribucin BGP

El tercer tipo de distribucin de etiquetas tambin se basa en un protocolo preexistente, BGP. BGP

tiene soporte para mltiples familias de direcciones, que hacen que sea fcil definir y llevar nuevos

tipos de informacin de accesibilidad y atributos asociados. Por lo tanto, mediante la adicin de

una nueva familia de direcciones de BGP, es posible publicar no slo un prefijo, sino tambin una o

ms etiquetas asociadas con el prefijo. En el captulo jerrquico e Inter-AS VPNs de este libro

(Captulo 9), veremos que esta capacidad es esencial en el contexto de la inter-AS / MPLS VPN. El

captulo describe varias soluciones en las que BGP se utiliza para:

(a) Distribuir las etiquetas 'interior' (etiquetas VPN) requeridas por el PE de salida para

identificar la instancia de servicio y el servicio que el paquete pertenece.

(b) Distribuir la etiqueta exterior requerida para transportar un paquete a la salida PE

apropiada.

(c) Las razones para escoger BGP como protocolo para la solucin son discutido en detalle en

el captulo jerrquica y el Inter-Como VPNs (Captulo 9). En este punto, vamos a ver algunos

de los beneficios aadidos de utilizando BGP para distribucin de etiquetas:

La capacidad de establecer LSP que cruzan COMO lmites. Un ejemplo de donde esto se

requiere es un servicio VPN basada en MPLS tener puntos de fijacin dentro de mltiples

proveedores. En este caso, es necesario distribuir etiquetas relativas a PE accesibilidad, por

lo que la etiqueta de transporte necesarios para llegar a un establecimiento permanente en

otro AS es conocido. BGP es el protocolo que se utiliza hoy para transmitir accesibilidad

informacin a travs COMO lmites; por lo tanto, puede transmitir fcilmente informacin

de la etiqueta a travs de fronteras.

Reduccin del nmero de los diferentes protocolos que se ejecutan en la red. En lugar de

desplegar un nuevo protocolo, reutilizacin uno de los protocolos existentes para

proporcionar una funcin ms.

Reutilizacin de las capacidades existentes del Protocolo. BGP es compatible con un

amplio conjunto de atributos que le permiten filtrar la informacin de enrutamiento, el

control de la seleccin de los puntos de salida, evitar bucles, etc. Todas estas capacidades

son fcilmente disponibles cuando la informacin se distribuye a lo largo de la etiqueta con

un prefijo.

1.4 CONCLUSIN

Hemos comenzado este captulo observando los objetivos originales del Grupo de Trabajo

MPLS en 1997. Como suele ser el caso de los tecnologas exitosas, MPLS se ha convertido

en un componente clave en la desarrollo de nuevas aplicaciones que no se previeron en el

inicio de MPLS. Los siguientes captulos se vern ms de cerca muchas de las innovaciones

posibles gracias a MPLS.

1.5 Referencias

[Davie Rekhter] B. Davie y Y. Rekhter, MPLS: Tecnologa

y Aplicaciones, Morgan Kaufmann, 2000

[Doyle Kolon] J. Doyle y M. Kolon (eds), Juniper Networks

Routers: The Complete Reference, McGraw-

Hill, 2002