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 d e 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 paq uete
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 ELSP y L-LSP.
E-LSP
El PHB es determinado por los bits EXP

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

Un solo PHB por LSP o varios PHBs con el

Puede transportar trfico con ms de 8 PHBs
mismo rgimen de planificacin y diferentes
distintos en un solo LSP
prioridades
Conservador uso de la etiqueta y el Utiliza ms etiquetas y mantiene ms estados,
mantenimiento del estado, porque la etiqueta porque la etiqueta transmite informacin
slo se utiliza para transportar informacin de sobre la ruta y el comportamiento de
la ruta
planificacin
No se requiere la sealizacin para transmitir La informacin PHB necesita sealizacin
la informacin PHB
cuando se establece el LSP
Hasta 8 PHBs pueden ser soportados en la red
cuando
slo
se
utilizan
E-LSP. Cualquier nmero de PHBs pueden ser
E-LSP se puede utilizar en conjunto con L-LSP soportados en la red...
cuando se requieren ms PHBs
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 s eccin. 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 implicacio nes:
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 usualme nte 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 diferen te 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
encontrar LSRs pares. Esto proporciona dos ventajas importantes:

de

descubrimiento

para

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 u n 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 nod o 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 RSVPsealado, 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 RSVPsealado 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. Po r 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 trav s 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 corefacing 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 as ociados
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, McGrawHill, 2002