MPLS

Arquitectura de conmutación de etiquetas multiprotocolo
Estado de esta nota
Este documento especifica un protocolo de seguimiento de estándares de Internet para

Comunidad de Internet, y solicita discusión y sugerencias para
mejoras. Por favor, consulte la edición actual de "Internet"
Estándares oficiales de protocolo "(STD 1) para el estado de estandarización
y el estado de este protocolo. La distribución de este memo es ilimitada.
Aviso de copyright
Copyright (C) The Internet Society (2001). Todos los derechos reservados.
Abstracto
Este documento especifica la arquitectura para la etiqueta multiprotocolo

Conmutación (MPLS).
Tabla de contenido
1 Especificación ...................................... 3
2 Introducción a MPLS ..... .......................... 3
2.1 Descripción general ..................... ...................... 4
2.2 Terminología ......................... ............... 6
2.3 Acrónimos y abreviaturas ......................... 9
2.4 Agradecimientos ... .................................. 9
3 Conceptos básicos de MPLS ............ ............................ 9
3.1 Etiquetas ................... .......................... 9
3.2 LSR en sentido ascendente y descendente ....................... 10
3.3 Paquete etiquetado .................. ................... 11
3.4 Asignación y distribución de etiquetas .................. 11
3.5 Atributos de un enlace de etiqueta .................... 11
3.6 Protocolos de distribución de etiquetas ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Modo de retención de etiqueta .............................. . 12
3.9 El Label pila .................................... 13
3.10 Entrada de reenvío de etiqueta del siguiente salto (NHLFE) ........ 13
3.11 Mapa de etiqueta entrante (ILM) ........................ ... 14
Rosen, et al. Normas Track [Page 1]
RFC 3031 MPLS Architecture Enero 2001
3.12 Mapa de FEC a NHLFE (FTN) ............................. 14

3.13 Intercambio de etiquetas ....... .............................. 15
3.14 Alcance y singularidad de las etiquetas ............. ........ 15
3.15 Ruta de etiqueta conmutada (LSP), LSP Ingress, LSP Egress. dieciséis
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ............. .......................... 20
3.18 Etiquetas entrantes no válidas ................... ......... 20
3.19 LSP Control: Ordenado versus Independiente ............ 20
3.20 Agregación .................. ...................... 21
3.21 Selección de ruta ........................ ............ 23
3.22 Falta de etiqueta saliente ............................. 24
3.23 Hora -to-Live (TTL) ................................. 24
3.24 Control de bucle ....................................... 25
3.25 Etiquetado de codificaciones .... ................................ 26
3.25.1 Hardware y / o software específico de MPLS ...... ....... 26
3.25.2 Interruptores ATM como LSR ........................... 26
3.25.3 Interoperabilidad entre técnicas de codificación ......... 28
3.26 Combinación de etiquetas ................................. ..... 28
3.26.1 LSR no fusibles ................................... 29
3.26 .2 Etiquetas para combinar LSR sin fusionar ............ 30
3.26.3 Fusión con ATM ................................... 31
3.26.3.1 Métodos de eliminación Intercalación de celdas ............. 31
3.26.3.2 Interoperación: Combinación de VC, fusión VP y no fusión ... 31
3.27 Túneles y jerarquía ............ .................. 32
3.27.1 Túnel enrutado Hop-by-Hop ..................... ...... 32
3.27.2 Túnel Explicitly Routed ........................... 33
3.27.3 Túneles LSP .... .................................... 33
3.27.4 Jerarquía: túneles LSP dentro de LSP ... ............. 33
3.27.5 Peering Distribution Jerarchy ........... 34
3.28 Protocolo de distribución de etiquetas Transporte .............. 35
3.29 ¿Por qué hay más de un protocolo de distribución de etiquetas? ..... 36
3.29.1 BGP y LDP ...................................... .. 36
3.29.2 Etiquetas para RSVP Flowspecs .......................... 36
3.29.3 Etiquetas para enrutados explícitamente LSP ..... ............. 36
3.30 Multidifusión .................................. ........ 37
4 Algunas aplicaciones de MPLS .......................... 37
4.1 MPLS y tráfico enrutado Hop-Hop ................. 37
4.1.1 Etiquetas para prefijos de dirección ................. ....... 37
4.1.2 Distribución de etiquetas para prefijos de dirección ........... 37
4.1.2.1 Pares de distribución de etiquetas para un prefijo de dirección ..... 37
4.1.2.2 Distribución de etiquetas. ............................... 38
4.1.3 Uso de la ruta Hop by Hop como LSP ...... ......... 39
4.1.4 Salida LSP Egress y LSP Proxy .................... 39
4.1.5 La etiqueta NULL implícita ... ......................... 40
4.1.6 Opción: Asignación de etiqueta dirigida a Egress ........... 40
4.2 MPLS y LSP enrutados explícitamente ........... 42
4.2 .1 Túneles LSP enrutados explícitamente .................. 42
4.3 Pilas de etiquetas y Peering implícito ............... ... 43
4.4 MPLS y enrutamiento de caminos múltiples ........................ 44

4.5 Árboles LSP como entidades multipunto a punto ........ .. 44
4.6 Túnel LSP entre BGP Border Routers ........... 45
4.7 Otros usos de Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS y Multicast ... .............................. 47
5 Procedimientos de distribución de etiquetas (Hop-by-Hop) ........ . 47
5.1 Los Procedimientos para Publicidad y Uso de etiquetas .... 48
5.1.1 Aguas abajo LSR: procedimiento de distribución ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional ....... ............................. 49
5.1.1.3 PulledUnconditional ................ ................ 49
5.1.1.4 PulledConditional ............................. ..... 50
5.1.2 LSR en sentido ascendente: Procedimiento de solicitud ....................
51
5.1.2.1 Solicitud nula ........... ............................ 51
5.1.2.2 Solicitudcuando sea necesario ................. ................. 51
5.1.2.3 RequestOnRequest ............................ ....... 51
5.1.3 LSR en sentido ascendente: procedimiento no disponible ............... 52
5.1.3.1 RequestRetry ...................... ................. 52
5.1.3.2 RequestNoRetry ............................ ......... 52
5.1.4 LSR en sentido ascendente: procedimiento de liberación ....................
52
5.1.4.1 ReleaseOnChange ....... ............................. 52
5.1.4.2 NoReleaseOnChange ................ .................. 53
5.1.5 LSR en sentido ascendente: labelUse Procedimiento ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 LSR en sentido descendente : Procedimiento de retirada ...... ...........
53
5.2 Esquemas MPLS: Combinaciones de procedimientos admitidos. 54
5.2.1 Esquemas para LSR que admiten fusión de etiquetas ........ 55
5.2.2 Esquemas para LSR que no admiten la fusión de etiquetas. 56
5.2.3 Consideraciones de interoperabilidad .................... 57
6 Consideraciones de Seguridad ..................... ....... 58
7 Propiedad Intelectual .............................. 58
8 Direcciones de los Autores .... ............................. 59
9 Referencias .................. ....................... 59
10 Declaración completa de los derechos de autor ...................... .....
61
1 . Especificación
Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBERÁ", "NO DEBERÁ",
"DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "MAYO" y "OPCIONAL" en este
documento debe interpretarse como se describe en RFC 2119 .
2 . Introducción a MPLS
Este documento especifica la arquitectura para la etiqueta multiprotocolo

Conmutación (MPLS).
Tenga en cuenta que el uso de MPLS para multidifusión queda en estudio.
2.1 . Visión de conjunto
Como un paquete de un protocolo de capa de red sin conexión viaja desde

de un enrutador al siguiente, cada enrutador realiza un reenvío independiente
decisión para ese paquete. Es decir, cada enrutador analiza el paquete
encabezado, y cada enrutador ejecuta un algoritmo de enrutamiento de capa de red. Cada
el enrutador elige de forma independiente un siguiente salto para el paquete, basado
en su
análisis del encabezado del paquete y los resultados de ejecutar el
algoritmo de enrutamiento.
Los encabezados de paquetes contienen mucha más información de la necesaria

simplemente para elegir el próximo salto. Por lo tanto, elegir el próximo salto puede
ser pensado como la composición de dos funciones. El primero
función divide el conjunto completo de paquetes posibles en un conjunto de
"Forwarding Equivalence Classes (FECs)". El segundo asigna cada FEC a
un próximo salto En lo que respecta a la decisión de reenvío,
diferentes paquetes que se mapean en el mismo FEC son
indistinguible. Todos los paquetes que pertenecen a un FEC particular y
que viajan desde un nodo particular seguirán el mismo camino (o si
ciertos tipos de enrutamiento de múltiples rutas están en uso, todos seguirán
uno de un conjunto de caminos asociados con el FEC).
En el reenvío de IP convencional, un enrutador en particular típicamente

considerar dos paquetes para estar en el mismo FEC si hay alguna dirección
prefijo X en las tablas de enrutamiento de ese enrutador de modo que X es el "más largo
coincidir "para la dirección de destino de cada paquete. Como el paquete
atraviesa la red, cada salto a su vez reexamina el paquete y
lo asigna a un FEC.
En MPLS, la asignación de un paquete particular a un FEC particular es

hecho una sola vez, a medida que el paquete ingresa a la red. La FEC a la cual
el paquete que se asigna está codificado como un valor corto de longitud fija conocido
como una "etiqueta". Cuando un paquete se reenvía a su siguiente salto, la etiqueta
se envía junto con eso; es decir, los paquetes están "etiquetados" antes de que
son enviados.
En saltos posteriores, no hay un análisis más detallado del paquete

encabezado de la capa de red. Más bien, la etiqueta se usa como un índice en un
tabla que especifica el siguiente salto y una nueva etiqueta. La vieja etiqueta
se reemplaza con la nueva etiqueta, y el paquete se reenvía a su
siguiente salto.
En el paradigma de reenvío de MPLS, una vez que se asigna un paquete a un FEC,

no hay más análisis de encabezado realizado por enrutadores posteriores; todas
el reenvío es impulsado por las etiquetas. Esto tiene una serie de ventajas
sobre el reenvío de capa de red convencional.
- El reenvío MPLS puede realizarse mediante conmutadores que son capaces de

haciendo búsqueda y reemplazo de etiquetas, pero o no son capaces
de analizar los encabezados de la capa de red, o no son capaces de
analizar los encabezados de la capa de red a la velocidad adecuada.
- Como un paquete está asignado a un FEC cuando ingresa a la red,

el enrutador de ingreso puede usar, al determinar la asignación, cualquier
información que tiene sobre el paquete, incluso si esa información
no se puede obtener del encabezado de la capa de red. Por ejemplo,
los paquetes que llegan a diferentes puertos pueden asignarse a
diferentes FEC. El reenvío convencional, por otro lado,
solo puede considerar la información que viaja con el paquete en
el encabezado del paquete
- Un paquete que ingresa a la red en un enrutador en particular puede ser

etiquetado de manera diferente que el mismo paquete que ingresa a la red
en un enrutador diferente, y como resultado, reenviar las decisiones
que dependen del enrutador de ingreso se puede hacer fácilmente. Esta
no se puede hacer con reenvío convencional, ya que la identidad
del enrutador de ingreso de un paquete no viaja con el paquete.
- Las consideraciones que determinan cómo se asigna un paquete a un

FEC puede ser cada vez más complicado, sin ningún
impacto en absoluto en los enrutadores que simplemente remiten etiquetados
paquetes
- A veces es deseable obligar a un paquete a seguir un

ruta particular que se elige explícitamente en o antes del
vez que el paquete ingresa a la red, en lugar de ser elegido por
el algoritmo de enrutamiento dinámico normal a medida que el paquete viaja
a través de la red. Esto se puede hacer como una cuestión de política,
o para apoyar la ingeniería de tráfico. En el envío convencional,
esto requiere que el paquete lleve una codificación de su ruta
junto con él ("enrutamiento de origen"). En MPLS, se puede usar una etiqueta
representar la ruta, de modo que la identidad de la persona explícita
la ruta no necesita ser transportada con el paquete.
Algunos enrutadores analizan el encabezado de la capa de red de un paquete no solo para

elija el próximo salto del paquete, pero también para determinar el paquete de
"precedencia" o "clase de servicio". Luego pueden aplicar diferentes
descartar umbrales o disciplinas de programación para diferentes paquetes.
MPLS permite (pero no requiere) la precedencia o clase de servicio
se infiere total o parcialmente de la etiqueta. En este caso, uno
puede decir que la etiqueta representa la combinación de un FEC y un
precedencia o clase de servicio.
Rosen, et al. Normas Track [Página 5]
MPLS significa cambio de etiqueta "multiprotocolo", multiprotocolo

porque sus técnicas son aplicables a CUALQUIER protocolo de capa de red.
En este documento, sin embargo, nos centramos en el uso de IP como red
protocolo de capa
Un enrutador que admite MPLS se conoce como "Enrutador de conmutación de etiquetas",

o LSR.
2.2 . Terminología
Esta sección ofrece una visión conceptual general de los términos utilizados en
este documento. Algunos de estos términos se definen con mayor precisión en
secciones posteriores del documento.
DLCI una etiqueta utilizada en redes Frame Relay para

identificar circuitos de retransmisión de tramas
expedir clase de equivalencia un grupo de paquetes IP que son

reenviado de la misma manera (por ejemplo,
sobre el mismo camino, con el mismo
reenvío de tratamiento)
fusión de etiquetas de combinación de marcos, cuando se aplica a

operación sobre medios basados en marcos, por lo
que el problema potencial de la célula
intercalar no es un problema.
etiquetar una corta longitud fija físicamente

identificador contiguo que se utiliza para
identificar un FEC, generalmente de
significado.
etiqueta fusionando el reemplazo de múltiples entrantes

etiquetas para un FEC particular con un
etiqueta saliente única
etiqueta intercambiar la operación de reenvío básico

que consiste en buscar un entrante
etiqueta para determinar la etiqueta saliente,
encapsulación, puerto y otros datos
manejo de la información.
etiqueta de intercambio de un paradigma de reenvío que permite

agilización de reenvío de datos mediante el uso
etiquetas para identificar clases de datos
paquetes que son tratados
indistinguiblemente cuando se reenvía.
etiqueta conmutada hop el salto entre dos nodos MPLS, en el cual

el reenvío se hace usando etiquetas.
ruta conmutada de etiqueta La ruta a través de uno o más LSR a la vez

nivel de jerarquía seguido por un
paquetes en un FEC particular.
enrutador de conmutación de etiquetas un nodo MPLS que es capaz de

reenvío de paquetes L3 nativos
capa 2, la capa de protocolo debajo de la capa 3 (que

por lo tanto, ofrece los servicios utilizados por
capa 3). Reenvío, cuando lo haga el
intercambio de etiquetas cortas de longitud fija,
ocurre en la capa 2 independientemente de si
la etiqueta que se examina es un cajero automático
VPI / VCI, un frame relay DLCI o un MPLS
etiqueta.
capa 3 la capa de protocolo en la que IP y su

protocolos de enrutamiento asociados operan
capa de enlace sinónimo con la capa 2
detección de bucle un método de tratar con bucles en el que

los bucles se pueden configurar y los datos
puede transmitirse por el bucle, pero
el bucle es detectado más tarde
prevención de bucles un método de tratar con bucles en el que

los datos nunca se transmiten a través de un bucle
etiqueta apila un conjunto ordenado de etiquetas
punto de fusión un nodo en el que se realiza la fusión de etiquetas
Dominio MPLS un conjunto contiguo de nodos que operan

Enrutamiento y reenvío MPLS y que
también están en un enrutamiento o
Dominio Administrativo
Nodo MPLS Edge un nodo MPLS que conecta un MPLS

dominio con un nodo que está fuera de
el dominio, ya sea porque no lo hace
ejecutar MPLS, y / o porque está en una
dominio diferente Tenga en cuenta que si un LSR
tiene un host vecino que no es
ejecutando MPLS, que ese LSR es un MPLS
nodo de borde.
Nodo de salida MPLS un nodo de borde MPLS en su rol en

manejar el tráfico ya que deja un MPLS
dominio
Nodo de entrada MPLS un nodo de borde MPLS en su rol en

manejar el tráfico cuando ingresa un MPLS
dominio
MPLS etiqueta una etiqueta que se lleva en un paquete

encabezado, y que representa el
paquete FEC
Nodo MPLS un nodo que ejecuta MPLS. Un MPLS

nodo será consciente del control MPLS
protocolos, operará uno o más L3
protocolos de enrutamiento, y será capaz
de paquetes de reenvío basados en etiquetas.
Un nodo MPLS puede ser opcionalmente también
capaz de reenviar paquetes L3 nativos.
Etiqueta MultiProtocol Conmutación de un grupo de trabajo IETF y

esfuerzo asociado con el trabajo
grupo
capa de red sinónimo de capa 3
pila con pila de etiquetas
ruta conmutada sinónimo de ruta conmutada de etiqueta
circuito virtual un circuito utilizado por una conexión orientada

tecnología de capa 2 como ATM o Frame
Relé, que requiere el mantenimiento de
información de estado en switches de capa 2.
Combinación de combinación de etiquetas de VC donde se encuentra la etiqueta MPLS

llevado en el campo ATM VCI (o
campo combinado VPI / VCI), para permitir
múltiples VCs para fusionarse en un solo VC
Combinación de fusión de etiqueta VP donde se encuentra la etiqueta MPLS

llevado din al campo ATM VPI, para
permitir que varios PV se fusionen en uno
solo VP. En este caso, dos células
tienen el mismo valor de VCI solo si
originado desde el mismo nodo. Esta
permite que las células de diferentes fuentes
distinguirse a través del VCI.
VPI / VCI una etiqueta utilizada en redes de ATM para identificar

circuitos
2.3 . Acrónimos y abreviaturas
Modo de transferencia asincrónica ATM

BGP Border Gateway Protocol
Identificador de circuito de enlace de datos DLCI
Clase de equivalencia de reenvío FEC
FTN FEC a NHLFE Mapa
Protocolo de puerta de enlace interior IGP
Mapa de etiquetas entrantes de ILM
Protocolo de Internet IP
Protocolo de distribución de etiquetas LDP
L2 Layer 2 L3 Layer 3
LSP Label Switched Path
Enrutador de conmutación de etiquetas LSR
Conmutación de etiquetas MPLS MultiProtocol
NHLFE Next Hop Label Reenvío de entrada
Circuito virtual conmutado SVC
SVP Switched Virtual Path
TTL Time-To-Live
Circuito virtual de VC
Identificador de circuito virtual VCI
Ruta virtual VP
Identificador de ruta virtual VPI
2.4 . Expresiones de gratitud
Las ideas y el texto en este documento se han recopilado de un número

de fuentes y comentarios recibidos. Quisiéramos agradecer a Rick
Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan,
y George Swallow por sus aportaciones e ideas.
3 . Conceptos básicos de MPLS
En esta sección, presentamos algunos de los conceptos básicos de MPLS y

describir el enfoque general que se utilizará.
3.1 . Etiquetas
Una etiqueta es un identificador corto, de longitud fija y significativo localmente

que se usa para identificar un FEC. La etiqueta que se pone en una
paquete particular representa la clase de equivalencia de reenvío a
que ese paquete está asignado.
Más comúnmente, un paquete se asigna a un FEC basado (completamente o

parcialmente) en su dirección de destino de capa de red. sin embargo, el
la etiqueta nunca es una codificación de esa dirección.
Si Ru y Rd son LSR, pueden acordar que cuando Ru transmite un paquete

a Rd, Ru etiquetará con paquete con el valor de etiqueta L si y solo si
el paquete es miembro de un FEC F particular. Es decir, pueden
acuerda una "unión" entre la etiqueta L y FEC F para el cambio de paquetes
de Ru a Rd. Como resultado de tal acuerdo, L se convierte en Ru
"etiqueta saliente" que representa FEC F, y L se convierte en "entrante" de Rd.
etiqueta "que representa FEC F.
Tenga en cuenta que L no representa necesariamente FEC F para ningún paquete

que no sean los que se envían desde Ru a Rd. L es un
valor arbitrario cuyo enlace a F es local a Ru y Rd.
Cuando hablamos arriba de los paquetes "siendo enviados" de Ru a Rd, no

implican que el paquete se originó en Ru o que su destino
es Rd. Más bien, queremos incluir paquetes que son "tránsito"
paquetes "en uno o ambos LSR.
A veces puede ser difícil o incluso imposible para Rd contar, de

un paquete que llega con la etiqueta L, en el que se colocó la etiqueta L
el paquete por Ru, en lugar de por otro LSR. (Esta voluntad
normalmente es el caso cuando Ru y Rd no son vecinos directos.) En
tales casos, Rd debe asegurarse de que la unión de la etiqueta a FEC sea
doce y cincuenta y nueve de la noche. Es decir, Rd NO DEBE estar de acuerdo con Ru1
para unir L a FEC F1,
mientras que también está de acuerdo con algún otro LSR Ru2 para unir L a un diferente
FEC F2, A MENOS QUE Rd siempre sepa, cuando recibe un paquete con
etiqueta L entrante, si la etiqueta fue puesta en el paquete por Ru1 o
si fue puesto por Ru2.
Es responsabilidad de cada LSR asegurarse de que pueda hacerlo de manera única

interpretar sus etiquetas entrantes.
3.2 . LSR ascendentes y descendentes
Supongamos que Ru y Rd han acordado atar la etiqueta L a FEC F, para paquetes

enviado desde Ru a Rd. Entonces con respecto a este enlace, Ru es el
"LSR aguas arriba", y Rd es el "LSR aguas abajo".
Decir que un nodo está en sentido ascendente y uno está en sentido descendente con
respecto
a un enlace determinado significa que una etiqueta en particular representa una
FEC particular en paquetes que viajan desde el nodo ascendente al
nodo aguas abajo. Esto NO pretende implicar que los paquetes en ese FEC
en realidad sería enrutado desde el nodo de aguas arriba a aguas abajo
nodo.
3.3 . Paquete etiquetado

Un "paquete etiquetado" es un paquete en el que se ha codificado una etiqueta.
En algunos casos, la etiqueta reside en un encabezado de encapsulación que
existe específicamente para este propósito. En otros casos, la etiqueta puede
residir en un enlace de datos existente o un encabezado de capa de red, siempre que
hay un campo que está disponible para ese propósito. Lo particular
La técnica de codificación que debe utilizarse debe ser aceptada por la entidad
que codifica la etiqueta y la entidad que decodifica la etiqueta.
3.4 . Asignación y distribución de etiquetas
En la arquitectura MPLS, la decisión de vincular una etiqueta particular L

a un FEC F en particular es hecho por el LSR que es ABAJO con
respecto a esa unión. El LSR aguas abajo informa al
aguas arriba LSR de la unión. Por lo tanto, las etiquetas están "asignadas en sentido
descendente",
y las vinculaciones de etiquetas se distribuyen en "aguas abajo a aguas arriba"
dirección.
Si se ha diseñado un LSR para que solo pueda buscar etiquetas que

caer en un cierto rango numérico, entonces simplemente necesita asegurar
que solo une las etiquetas que están en ese rango.
3.5 . Atributos de un enlace de etiqueta
Una unión particular de la etiqueta L a FEC F, distribuida por Rd a Ru,

puede tener "atributos" asociados. Si Ru, actuando como un LSR aguas abajo,
también distribuye un enlace de una etiqueta a FEC F, luego bajo cierta
condiciones, puede ser necesario distribuir también el
atributo que recibió de Rd.
3.6 . Protocolos de distribución de etiquetas
Un protocolo de distribución de etiquetas es un conjunto de procedimientos mediante el

cual un LSR
informa a otro de los enlaces de etiqueta / FEC que ha realizado. Dos LSR
que utilizan un protocolo de distribución de etiquetas para cambiar la etiqueta / unión
FEC
información se conocen como "pares de distribución de etiquetas" con respecto a
la información vinculante que intercambian. Si dos LSR son etiqueta
compañeros de distribución, hablaremos de que existe una "etiqueta"
distribución adyacente "entre ellos.
(NB: dos LSR pueden ser pares de distribución de etiquetas con respecto a algunos
conjunto de enlaces, pero no con respecto a algún otro conjunto de enlaces.)
El protocolo de distribución de etiquetas también abarca cualquier negociación en

qué dos pares de distribución de etiquetas deben participar para aprender
de las capacidades MPLS de los demás.
LA ARQUITECTURA NO ASUME QUE HAY SOLO UNA ETIQUETA INDIVIDUAL

PROTOCOLO DE DISTRIBUCIÓN. De hecho, una cantidad de etiquetas diferentes
los protocolos de distribución están siendo estandarizados. Protocolos existentes
se han extendido para que la distribución de etiquetas se pueda llevar a cuestas
ellos (ver, por ejemplo, [ MPLS-BGP ], [ MPLS-RSVP-TUNNELS ]). Nuevos protocolos
también se han definido con el propósito explícito de distribuir
etiquetas (véase, por ejemplo, [ MPLS-LDP ], [ MPLS-CR-LDP ].
En este documento, tratamos de usar el acrónimo "LDP" para referirnos

específicamente al protocolo definido en [ MPLS-LDP ]; cuando se habla de
protocolos de distribución de etiquetas en general, tratamos de evitar el acrónimo.
3.7 . Downstream-on-Demanda no solicitado Downstream vs. Down-on-Demand
La arquitectura MPLS permite que un LSR solicite explícitamente, desde su

próximo salto para un FEC en particular, una etiqueta vinculante para ese FEC. Esto es
conocida como distribución de etiquetas "downstream-on-demand".
La arquitectura MPLS también permite que un LSR distribuya enlaces a

LSR que no los han solicitado explícitamente. Esto se conoce como
distribución de etiquetas "no solicitadas aguas abajo".
Se espera que algunas implementaciones de MPLS brinden solo

distribución de etiquetas aguas abajo a pedido, y algunas proporcionarán solo
distribución de etiquetas aguas abajo no solicitada, y algunos proporcionarán
ambos. El que se proporciona puede depender de las características de
interfaces que son compatibles con una implementación particular.
Sin embargo, ambas técnicas de distribución de etiquetas se pueden usar en
la misma red al mismo tiempo. En cualquier distribución de etiqueta dada
adyacencia, el LSR aguas arriba y el LSR aguas abajo deben acordar
qué técnica se va a utilizar.
3.8 . Modo de retención de etiqueta
Un LSR Ru puede recibir (o haber recibido) un enlace de etiqueta para un

FEC particular de una LSR Rd, aunque Rd no es el próximo salto de Ru
(o ya no es el próximo salto de Ru) para ese FEC.
Ru entonces tiene la opción de hacer un seguimiento de tales enlaces, o

si descartar tales enlaces. Si Ru realiza un seguimiento de tal
enlaces, entonces puede comenzar inmediatamente a usar el enlace de nuevo si Rd
finalmente se convierte en su próximo salto para la FEC en cuestión. Si Ru
descarta tales enlaces, luego si Rd más tarde se convierte en el siguiente salto, el
vinculante tendrá que ser readquirido.
Si un LSR admite el "Modo de retención de etiqueta liberal", mantiene el

vinculaciones entre una etiqueta y un FEC que se reciben de LSR que
no es su próximo salto para ese FEC. Si un LSR admite "conservador
Modo de retención de etiquetas ", descarta tales enlaces.
El modo de retención de etiqueta liberal permite una adaptación más rápida al

enrutamiento
cambios, pero el modo conservador de retención de etiquetas requiere un LSR
para mantener muchas menos etiquetas.
3.9 . La pila de etiquetas

Hasta ahora, hemos hablado como si un paquete etiquetado llevara solo un solo
etiqueta. Como veremos, es útil tener un modelo más general en
que un paquete etiquetado lleva una cantidad de etiquetas, organizadas como
pila de último en entrar, primer en salir. Nos referimos a esto como una "pila de
etiquetas".
Aunque, como veremos, MPLS admite una jerarquía, el procesamiento

de un paquete etiquetado es completamente independiente del nivel de
jerarquía. El procesamiento siempre se basa en la etiqueta superior, sin
considerar la posibilidad de que algunas otras etiquetas puedan tener
estado "arriba" en el pasado, o que algunas otras etiquetas pueden
estar debajo de él en este momento.
Un paquete sin etiqueta se puede considerar como un paquete cuya pila de etiquetas
está vacío (es decir, cuya pila de etiquetas tiene profundidad 0).
Si la pila de etiquetas de un paquete es de profundidad m, nos referimos a la etiqueta

en el
parte inferior de la pila como la etiqueta de nivel 1, a la etiqueta que está encima
(si
tal existe) como la etiqueta de nivel 2, y a la etiqueta en la parte superior de la
pila como la etiqueta del nivel m.
La utilidad de la pila de etiquetas se aclarará cuando presentamos

la noción de túnel LSP y la jerarquía MPLS ( sección 3.27 ).
3.10 . Entrada de reenvío de etiqueta de siguiente salto (NHLFE)
La "Entrada de reenvío de etiqueta de siguiente salto" (NHLFE) se utiliza al reenviar

un paquete etiquetado Contiene la siguiente información:
1. el próximo salto del paquete
2. la operación a realizar en la pila de etiquetas del paquete; este es uno

de las siguientes operaciones:
a) reemplace la etiqueta en la parte superior de la pila de etiquetas con un

nueva etiqueta especificada
b) abrir la pila de etiquetas
c) reemplace la etiqueta en la parte superior de la pila de etiquetas con un

nueva etiqueta especificada, y luego presione uno o más nuevos especificados
etiquetas en la pila de etiquetas.
También puede contener:
d) la encapsulación del enlace de datos para usar cuando se transmite el paquete
e) la forma de codificar la pila de etiquetas cuando se transmite el paquete
f) cualquier otra información necesaria para disponer adecuadamente de

el paquete.
Tenga en cuenta que en un LSR dado, el "siguiente salto" del paquete podría ser ese
LSR
sí mismo. En este caso, el LSR necesitaría mostrar la etiqueta de nivel superior,
y luego "reenviar" el paquete resultante a sí mismo. Entonces sería
tomar otra decisión de reenvío, basada en lo que queda después del
la etiqueta apilada aparece. Esto aún puede ser un paquete etiquetado, o
puede ser el paquete IP nativo.
Esto implica que, en algunos casos, el LSR puede necesitar operar en el IP

encabezado para reenviar el paquete.
Si el "siguiente salto" del paquete es el LSR actual, entonces la pila de etiquetas
la operación DEBE ser "abrir la pila".
3.11 . Mapa de etiquetas entrantes (ILM)
El "Mapa de etiquetas entrantes" (ILM) asigna cada etiqueta entrante a un conjunto de

NHLFEs. Se usa al reenviar paquetes que llegan etiquetados
paquetes
Si el ILM asigna una etiqueta particular a un conjunto de NHLFEs que contiene

más de un elemento, se debe elegir exactamente un elemento del conjunto
antes de que el paquete sea enviado. Los procedimientos para elegir una
el elemento del conjunto está más allá del alcance de este documento. Teniendo
el ILM asigna una etiqueta a un conjunto que contiene más de un NHLFE puede ser
útil si, por ejemplo, se desea hacer balance de carga sobre múltiples
rutas de igual costo.
3.12 . Mapa de FEC a NHLFE (FTN)
El "FEC-a-NHLFE" (FTN) mapea cada FEC a un conjunto de NHLFEs. Es

utilizado al reenviar paquetes que llegan sin etiqueta, pero que son
ser etiquetado antes de ser enviado.
Si la FTN asigna una etiqueta particular a un conjunto de NHLFEs que contiene

más de un elemento, se debe elegir exactamente un elemento del conjunto
antes de que el paquete sea enviado. Los procedimientos para elegir una
el elemento del conjunto está más allá del alcance de este documento. Teniendo
el mapa FTN una etiqueta a un conjunto que contiene más de un NHLFE puede ser
útil si, por ejemplo, se desea hacer balance de carga sobre múltiples
rutas de igual costo.
3.13 . Intercambio de etiquetas
El intercambio de etiquetas es el uso de los siguientes procedimientos para reenviar

un
paquete.
Para reenviar un paquete etiquetado, un LSR examina la etiqueta en el

parte superior de la pila de etiquetas. Utiliza el ILM para asignar esta etiqueta a un
NHLFE. Usando la información en el NHLFE, determina dónde
reenviar el paquete y realiza una operación en la etiqueta del paquete
apilar. Luego codifica la nueva pila de etiquetas en el paquete, y
reenvía el resultado.
Para reenviar un paquete sin etiqueta, un LSR analiza la red

encabezado de capa, para determinar el FEC del paquete. Luego usa el FTN para
mapea esto a un NHLFE. Usando la información en el NHLFE,
determina dónde reenviar el paquete y realiza una operación en
la pila de etiquetas del paquete. (Aparecer la pila de etiquetas sería, por supuesto,
ser ilegal en este caso.) Luego codifica la nueva pila de etiquetas en
el paquete, y reenvía el resultado.
ES IMPORTANTE TENER EN CUENTA QUE CUANDO LA ETIQUETA ESTÁ EN USO, LA PRÓXIMA

HOP SIEMPRE ES TOMADO DE LA NHLFE; ESTO PUEDE EN ALGUNOS CASOS SER
DISTINTO DE LO QUE EL PRÓXIMO HOP SERÍA SI EL MPLS NO ESTÁ EN USO.
3.14 . Alcance y unicidad de las etiquetas
Una LSR Rd determinada puede unir la etiqueta L1 a FEC F y distribuirla

vinculante para el distribuidor de etiquetas peer Ru1. Rd también puede unir la etiqueta
L2 a
FEC F, y distribuir ese enlace al par de distribución de etiquetas Ru2.
Si la arquitectura determina o no L1 == L2; esta
es un asunto local.
Una LSR Rd determinada puede unir la etiqueta L a FEC F1 y distribuirla

vinculante para el distribuidor de etiquetas peer Ru1. Rd también puede unir la etiqueta
L a
FEC F2, y distribuir ese enlace al par de distribución de etiquetas Ru2.
SI (Y SÓLO SI) RD PUEDE DECIR, CUANDO RECIBE UN PAQUETE CUYO TOP
LA ETIQUETA ES L, YA SEA QUE LA ETIQUETA FUE PUESTA POR RU1 O POR RU2, ENTONCES
LA ARQUITECTURA NO REQUIERE QUE F1 == F2. En tales casos, nosotros
puede decir que Rd está usando un "espacio de etiqueta" diferente para las etiquetas
que
distribuye a Ru1 que para las etiquetas que distribuye a Ru2.
En general, Rd solo puede decir si fue Ru1 o Ru2 que puso el

valor de etiqueta particular L en la parte superior de la pila de etiquetas si el
se cumplen las siguientes condiciones:
- Ru1 y Ru2 son los únicos pares de distribución de etiquetas a los que Rd
distribuido un enlace de valor de etiqueta L, y
- Ru1 y Ru2 están conectados directamente a Rd a través de un punto-a-

interfaz de punto.
Cuando se cumplen estas condiciones, un LSR puede usar etiquetas que tengan "por
"interfaz", es decir, que son únicos por interfaz.
decir que el LSR está utilizando un "espacio de etiqueta por interfaz". Cuando estos
las condiciones no se cumplen, las etiquetas deben ser únicas sobre el LSR que
les ha asignado, y podemos decir que el LSR está usando un "per-
espacio de etiqueta de la plataforma ".
Si un LSR Rd particular está unido a un LSR Ru particular sobre dos

interfaces de punto a punto, entonces Rd puede distribuir a Ru un enlace de
etiqueta L a FEC F1, así como una unión de la etiqueta L a FEC F2, F1! =
F2, si y solo si cada enlace es válido solo para paquetes que Ru
envía a Rd sobre una de las interfaces en particular. En todos los demás
casos, Rd NO DEBE distribuir a enlaces Ru del mismo valor de etiqueta
a dos FEC diferentes.
Esta prohibición se mantiene incluso si se considera que las consolidaciones están en

diferentes "niveles de jerarquía". En MPLS, no hay noción de
tener un espacio de etiqueta diferente para diferentes niveles de la jerarquía;
al interpretar una etiqueta, el nivel de la etiqueta es irrelevante.
Surge la pregunta si es posible usar un LSR

múltiples espacios de etiquetas por plataforma, o para usar múltiples por interfaz
espacios de etiquetas para la misma interfaz. Esto no está prohibido por el
arquitectura. Sin embargo, en tales casos, el LSR debe tener algún medio,
no especificado por la arquitectura, de determinar, para un particular
etiqueta entrante, que etiqueta el espacio al que pertenece la etiqueta. por
ejemplo, [ MPLS-SHIM ] especifica que se usa un espacio de etiqueta diferente
para paquetes de unidifusión que para paquetes de multidifusión y utiliza un enlace de
datos
punto de código de capa para distinguir los dos espacios de etiqueta.
3.15 . Ruta de etiqueta conmutada (LSP), LSP Ingress, LSP Egress
Una "Ruta Conmutada por Etiquetas (LSP) de nivel m" para un paquete particular P es
una secuencia de enrutadores,
<R1, ..., Rn>
con las siguientes propiedades:
1. R1, el "LSP Ingress", es un LSR que empuja una etiqueta hacia P

pila de etiquetas, que da como resultado una pila de etiquetas de profundidad m;
2. Para todo i, 1 <i <n, P tiene una pila de etiquetas de profundidad m cuando se
recibe
por LSR Ri;
3. En ningún momento durante el tránsito de P de R1 a R [n-1] su etiqueta

pila alguna vez tiene una profundidad de menos de m;
4. Para todo i, 1 <i <n: Ri transmite P a R [i + 1] por medio de MPLS,

es decir, al usar la etiqueta en la parte superior de la pila de etiquetas (el
etiqueta de nivel m) como un índice en un ILM;
5. Para todo i, 1 <i <n: si un sistema S recibe y remite P después de P

es transmitido por Ri pero antes de que P sea recibido por R [i + 1] (ej.
Ri y R [i + 1] podrían estar conectados a través de un enlace de datos conmutados
subred, y S podría ser uno de los interruptores de enlace de datos), luego
La decisión de reenvío de S no se basa en la etiqueta de nivel m, o
en el encabezado de la capa de red. Esto puede ser porque:
a) la decisión no se basa en la pila de etiquetas o la red

encabezado de capa en absoluto;
b) la decisión se basa en una pila de etiquetas en la que

etiquetas se han empujado (es decir, en una etiqueta de nivel m + k, donde
k> 0).
En otras palabras, podemos hablar del nivel m LSP para el Paquete P como el
secuencia de enrutadores:
1. que comienza con un LSR (un "LSP Ingress") que empuja a un

nivel m etiqueta,
2. Todos los LSR intermedios toman su decisión de reenvío

por etiqueta Activando una etiqueta de nivel m,
3. que termina (en un "LSP Egreso") cuando se envía una decisión de reenvío
hecho por etiqueta Activando una etiqueta de nivel mk, donde k> 0, o
cuando una decisión de reenvío se realiza por "ordinario", no MPLS
procedimientos de reenvío.
Una consecuencia (o tal vez una presuposición) de esto es que siempre que
un LSR empuja una etiqueta en un paquete ya etiquetado, necesita
asegúrese de que la nueva etiqueta corresponde a un FEC cuyo LSP Egress es
el LSR que asignó la etiqueta que ahora es el segundo en la pila.

Llamaremos a una secuencia de LSR el "LSP para un FEC F particular" si
es un LSP de nivel m para un paquete particular P cuando el nivel m de P
etiqueta es una etiqueta que corresponde a FEC F.
Considere el conjunto de nodos que pueden ser nodos de ingreso LSP para FEC F.
Luego hay un LSP para FEC F que comienza con cada uno de esos nodos.
Si varios de esos LSP tienen la misma salida LSP, entonces uno puede
considerar el conjunto de tales LSP como un árbol, cuya raíz es el LSP
salida. (Dado que los datos viajan a lo largo de este árbol hacia la raíz, esto
puede llamarse árbol multipunto-a-punto.) Podemos hablar así del
"Árbol LSP" para un FEC F. particular
3.16 . Penultimate Hop Popping
Tenga en cuenta que de acuerdo con las definiciones de la sección 3.15 , si <R1, ...,
Rn> es un nivel m LSP para el paquete P, P puede transmitirse desde R [n-1]
a Rn con una pila de etiquetas de profundidad m-1. Es decir, la pila de etiquetas puede
aparecer en el penúltimo LSR del LSP, en lugar de en el LSP
Salida.
Desde una perspectiva arquitectónica, esto es perfectamente apropiado.

El objetivo de la etiqueta de nivel m es llevar el paquete a Rn. Una vez
R [n-1] ha decidido enviar el paquete a Rn, la etiqueta ya no tiene
cualquier función, y ya no necesita ser transportada.
También hay una ventaja práctica para hacer penultimate hop popping.
Si uno no hace esto, entonces cuando la salida LSP recibe un paquete,
primero busca la etiqueta superior y determina como resultado de eso
búsqueda que es de hecho la salida LSP. Luego debe hacer estallar la pila,
y examina lo que queda del paquete. Si hay otra etiqueta en
la pila, la salida buscará esto y reenviará el paquete
en esta búsqueda. (En este caso, la salida para el nivel del paquete m
LSP es también un nodo intermedio para su nivel m-1 LSP). Si hay
ninguna otra etiqueta en la pila, entonces el paquete se envía de acuerdo
a su dirección de destino de capa de red. Tenga en cuenta que esto
requiere la salida para hacer DOS búsquedas, ya sea dos búsquedas de etiquetas o una
búsqueda de etiqueta seguida de una búsqueda de dirección.
Si, por otro lado, se usa penultimate hop popping, entonces cuando el
penúltimo hop busca la etiqueta, determina:
- que es el penúltimo salto, y
- quién es el próximo salto.
El penúltimo nodo muestra la pila y reenvía el paquete

basado en la información obtenida al buscar la etiqueta que fue
anteriormente en la parte superior de la pila. Cuando la salida LSP recibe el
paquete, la etiqueta que ahora está en la parte superior de la pila será la

etiqueta que necesita buscar para hacer su propio reenvío
decisión. O, si el paquete solo llevaba una etiqueta, el
La salida de LSP simplemente verá el paquete de capa de red, que es solo
lo que necesita ver para tomar su decisión de reenvío.
Esta técnica permite que la salida haga una búsqueda única, y también
solo requiere una única búsqueda por el penúltimo nodo.
La creación del reenvío "vía rápida" en un cambio de etiqueta

El producto puede ser de gran ayuda si se sabe que solo una búsqueda
siempre se requiere:
- el código puede simplificarse si puede suponer que solo un único

siempre se necesita buscar
- el código puede basarse en un "presupuesto de tiempo" que asume que solo
solo se necesita una sola búsqueda.
De hecho, cuando se finaliza el penúltimo salto, el LSP Egress necesita

ni siquiera ser un LSR.
Sin embargo, algunos motores de conmutación de hardware pueden no ser capaces de abrir
pila de etiquetas, por lo que no se puede exigir universalmente. También puede haber
Hay algunas situaciones en las que no es deseable el salto del penúltimo salto.
Por lo tanto, el penúltimo nodo muestra la pila de etiquetas solo si esto es
específicamente solicitado por el nodo de salida, O si el siguiente nodo en el
LSP no es compatible con MPLS. (Si el siguiente nodo en el LSP no es compatible
MPLS, pero no hace tal solicitud, el penúltimo nodo no tiene
forma de saber que de hecho es el penúltimo nodo).
Un LSR que sea capaz de hacer estallar la pila de etiquetas DEBE hacer
penultimate hop popping cuando así lo solicita su etiqueta aguas abajo
par de distribución.
Las negociaciones iniciales del protocolo de distribución de etiquetas DEBEN permitir

cada LSR
para determinar si su vecino LSRS es capaz de hacer estallar el
pila de etiquetas A LSR NO DEBE solicitar un par de distribución de etiquetas para pop
la pila de etiquetas a menos que sea capaz de hacerlo.
Se puede preguntar si el nodo de salida siempre puede interpretar la parte superior

etiqueta de un paquete recibido correctamente si el salto del penúltimo salto es
usado. Siempre que las reglas de exclusividad y alcance de la sección 3.14
se obedecen, siempre es posible interpretar la etiqueta superior de
paquete recibido inequívocamente.
3.17 . LSP Next Hop
El siguiente salto de LSP para un paquete etiquetado en particular en un LSR particular

es el LSR que es el siguiente salto, según lo seleccionado por la entrada NHLFE utilizada
para reenviar ese paquete.
El siguiente salto de LSP para un FEC en particular es el próximo salto seleccionado

por
la entrada NHLFE indexada por una etiqueta que corresponde a esa FEC.
Tenga en cuenta que el LSP Next Hop puede diferir del próximo salto que lo haría
ser elegido por el algoritmo de enrutamiento de la capa de red. Usaremos el
el término "L3 próximo salto" cuando nos referimos a este último.
3.18 . Etiquetas entrantes no válidas
¿Qué debería hacer un LSR si recibe un paquete etiquetado con un

etiqueta entrante particular, pero no tiene ningún enlace para esa etiqueta? Es
tentador de pensar que las etiquetas solo se pueden quitar, y el paquete
reenviado como un paquete IP sin etiqueta. Sin embargo, en algunos casos, haciendo
entonces podría causar un bucle. Si el LSR aguas arriba cree que la etiqueta está
vinculada
a una ruta explícita, y el LSR indirecto no cree que la etiqueta
está ligado a cualquier cosa, y si el enrutamiento salto por salto de la etiqueta no
etiquetada
El paquete IP devuelve el paquete al LSR aguas arriba, luego se crea un ciclo
formado.
También es posible que la etiqueta estuviera destinada a representar una ruta

que no se puede inferir del encabezado IP.
Por lo tanto, cuando se recibe un paquete etiquetado con una entrada no válida
etiqueta, DEBE descartarse, A MENOS que se determine de alguna manera
(no dentro del alcance del documento actual) que lo reenvía
sin etiqueta no puede causar ningún daño.
3.19 . Control LSP: Ordenado versus Independiente
Algunos FEC corresponden a prefijos de direcciones que se distribuyen a través de un

algoritmo de enrutamiento dinámico. La configuración de los LSP para estos FEC puede
hacerse de una de dos maneras: control LSP independiente o LSP ordenado
Controlar.
En Independent LSP Control, cada LSR, al notar que reconoce

un FEC particular, toma una decisión independiente para vincular una etiqueta a
ese FEC y para distribuir ese enlace a su distribución de etiquetas
pares. Esto corresponde a la forma en que datagrama de IP convencional
enrutamiento funciona; cada nodo toma una decisión independiente sobre cómo
tratar cada paquete, y se basa en el algoritmo de enrutamiento para converger
rápidamente para asegurar que cada datagrama se entregue correctamente.
En Control LSP Ordenado, un LSR solo une una etiqueta a un FEC en particular
si es el LSR de egreso para ese FEC, o si ya ha recibido un
etiquetar vinculante para ese FEC desde su próximo salto para ese FEC.
Si uno quiere asegurarse de que el tráfico en un FEC particular siga un

ruta con un conjunto específico de propiedades (por ejemplo, que el tráfico
no atraviesa ningún nodo dos veces, que una cantidad específica de
recursos disponibles para el tráfico, que el tráfico sigue un
ruta explícitamente especificada, etc.) se debe usar el control ordenado. Con
control independiente, algunos LSR pueden comenzar a etiquetar cambiando un tráfico en
el FEC antes de que el LSP esté completamente configurado, y por lo tanto algo de
tráfico en
el FEC puede seguir un camino que no tiene el conjunto especificado de
propiedades. El control ordenado también debe usarse si el reconocimiento
de la FEC es una consecuencia de la creación de la correspondiente
LSP.
La configuración ordenada de LSP puede iniciarse ya sea por el ingreso o por

salida.
El control ordenado y el control independiente son totalmente interoperables.

Sin embargo, a menos que todos los LSR en un LSP estén usando el control ordenado, el
efecto general en el comportamiento de la red es en gran medida el de la independencia
control, ya que uno no puede estar seguro de que un LSP no se usa hasta que se
completamente configurado.
Esta arquitectura permite la elección entre control independiente y

el control ordenado es un asunto local. Desde los dos métodos
Interwork, un LSR dado necesita soporte solo uno o el otro. En general
hablando, la elección del control independiente versus el ordenado no
parece tener algún efecto sobre los mecanismos de distribución de etiquetas que
necesita ser definido.
3.20 . Agregación
Una forma de dividir el tráfico en FEC es crear un FEC por separado
para cada prefijo de dirección que aparece en la tabla de enrutamiento. Sin embargo,
dentro de un dominio MPLS particular, esto puede dar como resultado un conjunto de FEC
de modo que todo el tráfico en todos esos FEC sigue la misma ruta. por
ejemplo, un conjunto de prefijos de dirección distintos podrían tener todos el mismo
nodo de salida e intercambio de etiquetas se pueden usar solo para obtener el
tráfico al nodo de salida. En este caso, dentro del dominio MPLS,
la unión de esos FEC es en sí misma un FEC. Esto crea una elección:
si una etiqueta distinta debe vincularse a cada componente FEC, o debe
etiqueta única estar obligado a la unión, y esa etiqueta se aplica a todos
tráfico en la unión?
El procedimiento de vincular una etiqueta única a una unión de FEC que es

en sí mismo un FEC (dentro de algún dominio), y de aplicar esa etiqueta a todos
el tráfico en la unión, se conoce como "agregación". El MPLS

la arquitectura permite la agregación. La agregación puede reducir el número
de etiquetas que son necesarias para manejar un conjunto particular de paquetes, y
también puede reducir la cantidad de tráfico de control de distribución de etiquetas
necesario.
Dado un conjunto de FEC que son "agregables" en un solo FEC, es

posible (a) agregarlos en un solo FEC, (b) agregarlos
en un conjunto de FEC, o (c) no agregarlos en absoluto. Por lo tanto, podemos
hablar de la "granularidad" de la agregación, con (a) ser el
"granularidad más grosera", y (c) es la "granularidad más fina".
Cuando se usa el control de orden, cada LSR debe adoptar, para un conjunto dado de
FECs, la granularidad utilizada por su próximo salto para esos FEC.
Cuando se usa control independiente, es posible que haya

dos LSR adyacentes, Ru y Rd, que agregan algún conjunto de FEC
diferentemente.
Si Ru tiene una granularidad más fina que Rd, esto no causa ningún problema.
Ru distribuye más etiquetas para ese conjunto de FEC que Rd. Esta
significa que cuando Ru necesita reenviar paquetes etiquetados en esos FEC para
Rd., Puede necesitar asignar n etiquetas en m etiquetas, donde n> m. Como un
opción, Ru puede retirar el conjunto de n etiquetas que ha distribuido,
y luego distribuir un conjunto de m etiquetas, correspondientes al nivel de Rd de
granularidad. Esto no es necesario para garantizar un funcionamiento correcto, pero
sí resulta en una reducción del número de etiquetas distribuidas por
Ru y Ru no están obteniendo ninguna ventaja en particular distribuyendo
la mayor cantidad de etiquetas. La decisión de hacer esto o no
es un asunto local.
Si Ru tiene una granularidad más gruesa que Rd (es decir, Rd ha distribuido n

etiquetas para el conjunto de FEC, mientras que Ru ha distribuido m, donde n> m),
tiene dos opciones:
- Puede adoptar el nivel de granularidad más fino de Rd. Esto sería

requerir que retire las m etiquetas que ha distribuido, y
distribuir n etiquetas. Esta es la opcion preferida.
- Simplemente puede mapear sus etiquetas m en un subconjunto de etiquetas Rd's n,

si puede determinar que esto producirá la misma ruta.
Por ejemplo, supongamos que Ru aplica una sola etiqueta a todos
el tráfico que necesita pasar a través de un cierto LSR de salida,
mientras Rd une varias etiquetas diferentes a dicho tráfico,
dependiendo de las direcciones de destino individuales de la
paquetes Si Ru conoce la dirección del enrutador de egreso, y si
Rd ha vinculado una etiqueta a la FEC que se identifica por ese
dirección, entonces Ru simplemente puede aplicar esa etiqueta.

En cualquier caso, cada LSR necesita saber (por configuración) qué

granularidad para usar para las etiquetas que asigna. Donde el control ordenado
se usa, esto requiere que cada nodo conozca la granularidad solo para
FEC que salen de la red MPLS en ese nodo. Para independiente
control, se pueden obtener mejores resultados asegurando que todos los LSR sean
Configurado de manera consistente para conocer la granularidad de cada FEC.
Sin embargo, en muchos casos esto se puede hacer utilizando un solo nivel de
granularidad que se aplica a todos los FEC (como "una etiqueta por IP")
prefijo en la tabla de reenvío ", o" una etiqueta por nodo de salida ").
3.21 . Selección de ruta
La selección de ruta hace referencia al método utilizado para seleccionar el LSP para
un
FEC en particular La arquitectura de protocolo MPLS propuesta admite dos
opciones para la selección de ruta: (1) ruta de salto por salto, y (2) explícita
enrutamiento
El enrutamiento Hop by hop permite que cada nodo elija de forma independiente el
siguiente
hop para cada FEC. Este es el modo habitual hoy en IP existente
redes. Un "LSP enrutado salto por salto" es un LSP cuya ruta es
seleccionado utilizando el enrutamiento salto por salto.
En un LSP explícitamente enrutado, cada LSR no elige de forma independiente

el próximo salto; más bien, un único LSR, generalmente el ingreso LSP o el
Egreso de LSP, especifica varios (o todos) de los LSR en el LSP. Si un
LSR único especifica todo el LSP, el LSP es "estrictamente" explícitamente
enrutado Si un solo LSR especifica solo algunos de los LSP, el LSP es
"vagamente" explícitamente encaminado.
La secuencia de LSR seguidos por un LSP explícitamente enrutado puede ser

elegido por configuración, o puede ser seleccionado dinámicamente por un solo
nodo (por ejemplo, el nodo de salida puede hacer uso de la topología
información aprendida de una base de datos de estado de enlace para calcular
la ruta completa del árbol que termina en ese nodo de salida).
El enrutamiento explícito puede ser útil para una serie de propósitos, como
enrutamiento de políticas o ingeniería de tráfico. En MPLS, la ruta explícita
debe especificarse en el momento en que se asignan las etiquetas, pero el
la ruta explícita no tiene que especificarse con cada paquete de IP.
Esto hace que el enrutamiento explícito MPLS sea mucho más eficiente que el
alternativa de enrutamiento de fuente de IP.
Los procedimientos para hacer uso de rutas explícitas, ya sean estrictas o

suelto, están más allá del alcance de este documento.
3.22 . Falta de etiqueta saliente
Cuando un paquete etiquetado viaja a lo largo de un LSP, puede ocasionalmente

sucede que alcanza un LSR en el que el ILM no mapea el
etiqueta entrante del paquete en un NHLFE, aunque la etiqueta entrante
es en sí mismo válido. Esto puede suceder debido a condiciones transitorias, o debido
a un error en el LSR que debería ser el próximo salto del paquete.
En tales casos, es tentador quitarse la pila de etiquetas e intentar
reenviar el paquete a través del reenvío convencional, basado en
su encabezado de capa de red. Sin embargo, en general, esto no es seguro
procedimiento:
- Si el paquete ha estado siguiendo un LSP explícitamente enrutado, esto

podría resultar en un bucle.
- El encabezado de red del paquete puede no contener suficiente información

para habilitar este LSR particular para reenviarlo correctamente.
A menos que se pueda determinar (por algún medio fuera del alcance de
este documento) que ninguna de estas situaciones obtiene, el único
procedimiento seguro es descartar el paquete.
3.23 . Time-to-Live (TTL)
En el reenvío de IP convencional, cada paquete lleva un "Tiempo para vivir"

(TTL) valor en su encabezado. Cuando un paquete pasa por un
enrutador, su TTL se reduce en 1; si el TTL llega a 0 antes
el paquete ha llegado a su destino, el paquete se descarta.
Esto proporciona cierto nivel de protección contra los bucles de reenvío que
puede existir debido a configuraciones incorrectas, o debido a fallas o lentitud
convergencia del algoritmo de enrutamiento. TTL a veces se usa para
otras funciones también, como alcance de multidifusión y soporte
el comando "traceroute". Esto implica que hay dos TTL-
problemas relacionados que MPLS necesita tratar: (i) TTL como una forma de
suprimir bucles; (ii) TTL como una forma de cumplir otras funciones, tales
como limitar el alcance de un paquete.
Cuando un paquete viaja a lo largo de un LSP, DEBE surgir con el mismo

Valor TTL que habría tenido si hubiera atravesado el mismo
secuencia de enrutadores sin haberse cambiado de etiqueta. Si el
el paquete viaja a lo largo de una jerarquía de LSP, el número total de LSR-
los saltos atravesados DEBERÍAN reflejarse en su valor de TTL cuando emerge
de la jerarquía de LSP.
La forma en que se maneja el TTL puede variar dependiendo de si el MPLS

los valores de etiqueta se transportan en un encabezado "shim" específico de MPLS [MPLS-
SHIM], o si las etiquetas MPLS se llevan en un encabezado L2, como un
Cabecera ATM [ MPLS-ATM ] o cabecera de retransmisión de trama [ MPLS-FRMRLY ].
Si los valores de la etiqueta están codificados en una "cuña" que se encuentra entre
el
el enlace de datos y los encabezados de la capa de red, entonces esta corrección DEBE
tener un TTL
campo que DEBE cargarse inicialmente desde el encabezado de la capa de red
El campo TTL, DEBE decrementarse en cada LSR-hop, y DEBERÍA ser
copiado en el campo TTL del encabezado de la capa de red cuando el paquete
emerge de su LSP.
Si los valores de la etiqueta están codificados en un encabezado de capa de enlace de

datos (por ejemplo,
el campo VPI / VCI en el encabezado AAL5 de ATM), y los paquetes etiquetados son
reenviado por un interruptor L2 (por ejemplo, un interruptor ATM) y el enlace de datos
capa (como ATM) no tiene un campo TTL, entonces no lo hará
ser posible disminuir el TTL de un paquete en cada LSR-hop. Un LSP
segmento que consiste en una secuencia de LSR que no puede disminuir una
el TTL del paquete se denominará "segmento LSP no TTL".
Cuando un paquete emerge de un segmento LSP no TTL, DEBERÍA, sin embargo,
recibir un TTL que refleje la cantidad de saltos LSR que atravesó. En
el caso unicast, esto se puede lograr propagando un significado
Longitud de LSP a los nodos de ingreso, lo que permite que el ingreso disminuya
Valor TTL antes de reenviar paquetes a un segmento LSP no TTL.
A veces se puede determinar, al ingresar a un LSP no TTL

segmento, que el TTL de un paquete en particular expirará antes del paquete
alcanza la salida de ese segmento LSP no TTL. En este caso, el
LSR en el ingreso al segmento LSP no TTL no debe etiquetar el interruptor
el paquete. Esto significa que deben desarrollarse procedimientos especiales para
admitir la funcionalidad de traceroute, por ejemplo, los paquetes traceroute pueden
ser reenviado usando el salto convencional por el reenvío de saltos.
3.24 . Control de bucle
En un segmento LSP no TTL, por definición, TTL no se puede usar para

proteger contra los bucles de reenvío. La importancia del control de bucle puede
Depende del hardware particular que se use para proporcionar el LSR
funciones a lo largo del segmento LSP no TTL.
Supongamos, por ejemplo, que el hardware de conmutación ATM se está utilizando para
proporcionar funciones de conmutación MPLS, con la etiqueta transportada en el
Campo VPI / VCI. Dado que el hardware de conmutación ATM no puede disminuir el TTL,
no hay protección contra los bucles. Si el hardware del cajero automático es capaz
de proporcionar un acceso justo al grupo de búferes para las células entrantes
portando diferentes valores de VPI / VCI, este bucle puede no tener ningún
efecto perjudicial en otro tráfico. Si el hardware del cajero automático no puede
proporcionar un acceso justo de buffer de este tipo, sin embargo, luego incluso
transitorio
los bucles pueden causar una grave degradación del rendimiento total del LSR.
Incluso si se puede proporcionar un acceso justo al buffer, aún vale la pena

tener algunos medios para detectar bucles que duren "más tiempo que sea posible".
Además, incluso donde TTL y / o colas justas por VC proporcionan una
medios para sobrevivir bucles, todavía puede ser deseable cuando sea práctico
para evitar la configuración de LSPs que buclean. Todos los LSR que pueden adjuntarse
a
Por lo tanto, se requerirán segmentos LSP no TTL para soportar un
técnica para la detección de bucles; Sin embargo, el uso de la detección de bucle
la técnica es opcional. La técnica de detección de bucle está especificada en
[ MPLS-ATM ] y [ MPLS-LDP ].
3.25 . Codificaciones de etiqueta
Para transmitir una pila de etiquetas junto con el paquete cuya etiqueta
pila es, es necesario definir una codificación concreta de la
pila de etiquetas La arquitectura admite varias codificaciones diferentes
técnicas; la elección de la técnica de codificación depende de la
tipo particular de dispositivo que se usa para reenviar paquetes etiquetados.
3.25.1 . Hardware y / o software MPLS-specific
Si uno usa hardware o software específico de MPLS para reenviar

paquetes etiquetados, la forma más obvia de codificar la pila de etiquetas es
definir un nuevo protocolo para ser utilizado como un "shim" entre el enlace de datos
capa y encabezados de capa de red. Esta cuña realmente sería solo una
encapsulación del paquete de capa de red; sería "protocolo"
independiente "de modo que pueda ser utilizado para encapsular cualquier red
capa. Por lo tanto, nos referiremos a él como el "MPLS genérico".
encapsulación ".
La encapsulación MPLS genérica a su vez se encapsularía en una

protocolo de capa de enlace de datos.
La encapsulación genérica de MPLS se especifica en [ MPLS-SHIM ].
3.25.2 . Interruptores ATM como LSR
Se observará que los procedimientos de reenvío MPLS son similares a los

de conmutadores heredados de "intercambio de etiquetas", como los conmutadores ATM.
Cajero automático
Los conmutadores usan el puerto de entrada y el valor VPI / VCI entrante como
índice en una tabla de "conexión cruzada", de la cual obtienen una salida
puerto y un valor saliente de VPI / VCI. Por lo tanto, si una o más etiquetas
se puede codificar directamente en los campos a los que acceden estos
conmutadores heredados, luego los conmutadores heredados pueden, con el software
adecuado
actualizaciones, se utilizarán como LSR. Nos referiremos a tales dispositivos como
"ATM-
LSRs ".
Hay tres formas obvias de codificar etiquetas en el encabezado de la celda ATM

(suponiendo el uso de AAL5):
1. Codificación SVC
Use el campo VPI / VCI para codificar la etiqueta que está en la parte superior
de la pila de etiquetas. Esta técnica se puede usar en cualquier red.
Con esta técnica de codificación, cada LSP se realiza como un cajero automático
SVC, y el protocolo de distribución de etiquetas se convierte en el cajero
automático
protocolo de "señalización". Con esta técnica de codificación, el ATM-
Los LSR no pueden realizar operaciones "push" o "pop" en la etiqueta
apilar.
2. Codificación SVP
Use el campo VPI para codificar la etiqueta que está en la parte superior de
la pila de etiquetas y el campo VCI para codificar la segunda etiqueta
en la pila, si hay uno presente. Esta técnica algunos
ventajas sobre la anterior, ya que permite el uso de
ATM "VP-switching". Es decir, los LSP se realizan como ATM
SVP, con el protocolo de distribución de etiquetas que sirve como cajero
automático
protocolo de señalización
Sin embargo, esta técnica no siempre se puede usar. Si la red

incluye una ruta virtual ATM a través de una red de cajeros automáticos no MPLS,
entonces el campo VPI no está necesariamente disponible para su uso por
MPLS.
Cuando se utiliza esta técnica de codificación, el ATM-LSR en la salida

del VP efectivamente hace una operación "pop".
3. Codificación multipunto SVP
Use el campo VPI para codificar la etiqueta que está en la parte superior de
la pila de etiquetas, use parte del campo VCI para codificar el segundo
etiqueta en la pila, si hay uno presente, y usa el resto de
el campo VCI para identificar el ingreso LSP. Si esta técnica
se usa, las capacidades de conmutación de VP ATM convencionales se pueden usar
para proporcionar VPs multipunto a punto. Células de diferentes
los paquetes llevarán diferentes valores de VCI. Como ya veremos
en la sección 3.26 , esto nos permite fusionar las etiquetas, sin
encontrándose con problemas de intercalación de celdas, en interruptores ATM
que pueden proporcionar VP multipunto a punto, pero que no
tener la capacidad de combinar VC.
Esta técnica depende de la existencia de una capacidad para

asignando valores de VCI de 16 bits a cada conmutador ATM de modo que no
el valor único de VCI se asigna a dos conmutadores diferentes. (Si una
se podría asignar un número adecuado de tales valores a cada

cambiar, también sería posible tratar el valor de VCI como
segunda etiqueta en la pila).
Si hay más etiquetas en la pila de las que se pueden codificar en el cajero automático
encabezado, las codificaciones ATM deben combinarse con el genérico
encapsulamiento
3.25.3 . Interoperabilidad entre técnicas de codificación
Si <R1, R2, R3> es un segmento de un LSP, es posible que R1

use una codificación de la pila de etiquetas cuando transmita el paquete P a R2,
pero R2 usará una codificación diferente cuando transmita un paquete P a
R3. En general, la arquitectura MPLS admite LSP con diferentes
codificaciones de la pila de etiquetas utilizadas en diferentes saltos. Por lo tanto,
cuando
discutir los procedimientos para procesar un paquete etiquetado, hablamos en
términos abstractos de operación en la pila de etiquetas del paquete. Cuando un
se recibe el paquete etiquetado, el LSR debe decodificarlo para determinar el
el valor actual de la pila de etiquetas, luego debe operar en la etiqueta
apilar para determinar el nuevo valor de la pila, y luego codificar el
nuevo valor apropiadamente antes de transmitir el paquete etiquetado a su
siguiente salto.
Desafortunadamente, los switches ATM no tienen capacidad para traducir desde

una técnica de codificación a otra. La arquitectura MPLS por lo tanto
requiere que siempre que sea posible que dos interruptores ATM sean
sucesivos LSR a lo largo de un nivel m LSP para algún paquete, que esos dos
Los conmutadores ATM utilizan la misma técnica de codificación.
Naturalmente, habrá redes MPLS que contienen una combinación de

Los conmutadores ATM que funcionan como LSR y otros LSR que funcionan utilizando un
MPLS shim encabezado. En tales redes, puede haber algunos LSR que tienen
Interfaces ATM, así como interfaces "MPLS Shim". Este es uno
ejemplo de un LSR con diferentes codificaciones de pila de etiquetas en diferentes
saltos Tal LSR puede intercambiar una pila de etiquetas codificadas ATM en un
interfaz entrante y reemplácela con un encabezado shim MPLS codificado
pila de etiquetas en la interfaz saliente.
3.26 . Combinación de etiquetas
Supongamos que un LSR ha vinculado múltiples etiquetas entrantes a un

FEC en particular Al reenviar paquetes en ese FEC, uno desearía
tener una sola etiqueta saliente que se aplica a todos esos paquetes.
El hecho de que dos paquetes diferentes en el FEC llegaron con diferentes
las etiquetas entrantes son irrelevantes; a uno le gustaría enviarlos con
la misma etiqueta de salida. La capacidad para hacerlo se conoce como "etiqueta
fusión ".
Digamos que un LSR es capaz de fusionarse con la etiqueta si puede recibir

dos paquetes de diferentes interfaces entrantes, y / o con diferentes
etiquetas, y enviar ambos paquetes fuera de la misma interfaz de salida con
la misma etiqueta. Una vez que los paquetes se transmiten, la información
que llegaron desde diferentes interfaces y / o con diferentes
las etiquetas entrantes se pierden.
Digamos que un LSR no es capaz de fusionarse con la etiqueta si, para cualquier
dos paquetes que llegan desde diferentes interfaces, o con diferentes
etiquetas, los paquetes deben ser transmitidos por diferentes
interfaces, o debe tener diferentes etiquetas. ATM-LSR usando el SVC o
Las codificaciones SVP no pueden realizar la fusión de etiquetas. Esto se discute en
más detalles en la siguiente sección.
Si un LSR particular no puede realizar la fusión de etiquetas, entonces si dos paquetes

en el mismo FEC llegan con diferentes etiquetas entrantes, deben ser
reenviado con diferentes etiquetas salientes. Con la fusión de etiquetas,
el número de etiquetas salientes por FEC solo necesita ser 1; sin etiqueta
fusionándose, el número de etiquetas salientes por FEC podría ser tan grande como
la cantidad de nodos en la red.
Con la fusión de etiquetas, el número de etiquetas entrantes por FEC que un

las necesidades particulares de LSR nunca son mayores que la cantidad de etiquetas
adyacencias de distribución. Sin fusión de etiquetas, la cantidad de
las etiquetas entrantes por FEC que necesita un LSR particular es tan grande como
la cantidad de nodos ascendentes que reenvían el tráfico en el FEC al
LSR en cuestión. De hecho, es difícil para un LSR incluso
determinar cuántas de esas etiquetas entrantes debe admitir un
FEC en particular
La arquitectura MPLS se adapta a los LSR fusionados y no fusibles,

pero permite el hecho de que puede haber LSR que no son compatibles
fusión de etiquetas. Esto lleva a la cuestión de garantizar la correcta
interoperación entre la fusión de LSR y LSR que no se fusionan. La cuestión
es algo diferente en el caso de los medios de datagramas versus el caso
de ATM. Por lo tanto, se discutirán los diferentes tipos de medios
por separado.
3.26.1 . LSR sin fusión
El procedimiento de reenvío MPLS es muy similar al reenvío

procedimientos utilizados por tecnologías tales como ATM y Frame Relay. Ese
es, llega una unidad de datos, se busca una etiqueta (VPI / VCI o DLCI) en
una "tabla de conexión cruzada", sobre la base de esa búsqueda un puerto de salida
se elige y se reescribe el valor de la etiqueta. De hecho, es posible
usar tales tecnologías para el reenvío de MPLS; una distribución de etiquetas
protocolo se puede utilizar como el "protocolo de señalización" para configurar el
tablas de conexión cruzada.
Desafortunadamente, estas tecnologías no necesariamente respaldan el

capacidad de fusión de etiquetas. En ATM, si uno intenta realizar la etiqueta
fusión, el resultado puede ser el entrelazado de células de diversos
paquetes Si las celdas de diferentes paquetes se entrelazan, es
imposible volver a armar los paquetes. Algunos interruptores Frame Relay usan
cambio de celda en sus backplanes. Estos interruptores también pueden ser
incapaz de apoyar la fusión de etiquetas, por la misma razón: células
de diferentes paquetes pueden intercalarse, y entonces no hay manera de
vuelve a armar los paquetes.
Proponemos apoyar dos soluciones a este problema. Primero, MPLS

contendrá procedimientos que permiten el uso de LSR que no se fusionan.
En segundo lugar, MPLS apoyará los procedimientos que permiten ciertos interruptores
ATM
para funcionar como fusión de LSR.
Dado que MPLS admite combinar tanto LSR como no fusionar, MPLS también
contiene procedimientos para asegurar la interoperación correcta entre ellos.
3.26.2 . Etiquetas para fusionar y LSR sin fusión
Un LSR ascendente que admite la fusión de etiquetas debe enviarse únicamente

una etiqueta por FEC. Un vecino aguas arriba que no admite etiqueta
la fusión debe enviarse varias etiquetas por FEC. Sin embargo, hay
no hay manera de saber a priori cuántas etiquetas necesita. Esta voluntad
Depende de cuántos LSRs están aguas arriba de él con respecto a la FEC en
pregunta.
En la arquitectura MPLS, si un vecino aguas arriba no lo hace

fusión de etiquetas de soporte, no se envía ninguna etiqueta para un FEC en particular
a menos que explícitamente solicite una etiqueta para ese FEC. La corriente arriba
el vecino puede hacer múltiples solicitudes de este tipo, y recibe una nueva etiqueta
cada vez. Cuando un vecino aguas abajo recibe dicha solicitud de
aguas arriba, y el vecino aguas abajo no es compatible con la etiqueta
fusionándose, entonces, a su vez, debe preguntarle a su vecino río abajo por otro
etiqueta para el FEC en cuestión.
Es posible que haya algunos nodos que admitan la etiqueta

fusionarse, pero solo puede fusionar un número limitado de etiquetas entrantes en
una sola etiqueta saliente. Supongamos, por ejemplo, que debido a algunos
limitación de hardware un nodo es capaz de fusionar cuatro etiquetas entrantes
en una sola etiqueta saliente. Supongamos, sin embargo, que este particular
nodo tiene seis etiquetas entrantes que llegan a él para un FEC particular. En
en este caso, este nodo puede fusionar estos en dos etiquetas salientes.
Si la fusión de etiquetas es aplicable a LSP explícitamente enrutados es para

estudio adicional.
3.26.3 . Fusionar en ATM
3.26.3.1 . Métodos para eliminar el intercalado celular
Hay varios métodos que se pueden usar para eliminar la célula

problema de entrelazado en ATM, lo que permite que los conmutadores ATM sean compatibles
fusión de flujo:
1. Combinación VP, utilizando la codificación multipunto SVP
Cuando se utiliza la combinación VP, se combinan varias rutas virtuales en una

ruta virtual, pero los paquetes de diferentes fuentes son
distinguido mediante el uso de diferentes VCI dentro de la VP.
2. fusión de VC
Cuando se utiliza la combinación de VC, se requieren conmutadores para almacenar

las celdas
de un paquete hasta que se reciba todo el paquete (esto puede
se determinará buscando el indicador del extremo del marco AAL5).
La fusión VP tiene la ventaja de que es compatible con una mayor

porcentaje de implementaciones de conmutadores ATM existentes. Esto lo hace
Es más probable que la combinación VP se pueda utilizar en redes existentes. diferente
a
Combinación de VC, fusión VP no incurre en demoras en los puntos de fusión y
tampoco impone ningún requisito de memoria intermedia. Sin embargo, tiene el
desventaja de que requiere la coordinación del espacio VCI dentro de
cada VP Hay varias formas en que esto se puede lograr.
La selección de uno o más métodos queda en estudio.
Esta compensación entre compatibilidad con equipos existentes versus

la complejidad y escalabilidad del protocolo implica que es deseable para
el protocolo MPLS para admitir fusión de VP y fusión de VC. A fin de que
hacerlo, cada conmutador ATM que participa en MPLS necesita saber si
Los vecinos de cajeros automáticos inmediatos realizan fusión de VP, combinación de VC
o ninguna combinación.
3.26.3.2 . Interoperación: VC Merge, VP Merge y Non-Merge
La interoperación de las diversas formas de fusión sobre ATM es más

se describe fácilmente describiendo primero la interoperación de la fusión de VC
con no fusión.
En el caso en que los nodos de fusión y no de VC están interconectados,

el reenvío de las celdas se basa en todos los casos en un VC (es decir, el
concatenación del VPI y VCI). Para cada nodo, si es un flujo ascendente
vecino está haciendo fusión de VC luego que el vecino aguas arriba requiere solo
un solo VPI / VCI para un flujo en particular (esto es análogo al
requisito para una sola etiqueta en el caso de operación sobre marco
medios de comunicación). Si el vecino aguas arriba no se está fusionando, entonces el
vecino requerirá un solo VPI / VCI por secuencia para sí mismo, más
suficientes VPI / VCIs para pasar a sus vecinos aguas arriba. El número
requerido se determinará permitiendo que los nodos ascendentes soliciten
VPI / VCI adicionales de sus vecinos aguas abajo (esto es nuevamente
análogo al método utilizado con fusión de cuadros).
Un método similar es posible para admitir nodos que realizan fusión VP.
En este caso, el nodo de fusión VP, en lugar de solicitar un solo
VPI / VCI o varios VPI / VCI de su vecino de aguas abajo, en cambio
puede solicitar un único VP (identificado por un VPI) pero varios VCI dentro de
el VP Además, supongamos que un nodo que no es de fusión está aguas abajo
de dos diferentes nodos de fusión VP. Este nodo puede necesitar solicitar uno
VPI / VCI (para el tráfico que se origina a partir de sí mismo) más dos VP (uno para
cada nodo ascendente), cada uno asociado a un conjunto específico de VCI (como
solicitado desde el nodo ascendente).
Con el fin de admitir todo el VP Merge, VC merge y non-merge, es

por lo tanto, es necesario permitir que los nodos ascendentes soliciten una combinación
de cero o más identificadores de VC (que consisten en un VPI / VCI), más cero
o más VP (identificados por VPI) cada uno con un número especificado
de VCs (identificados por un conjunto de VCI que son significativos dentro de
VP). Por lo tanto, los nodos de fusión VP solicitarían un VP, con un contenido
VCI para el tráfico que origina (si corresponde) más un VCI para
cada VC solicitado desde arriba (independientemente de si el VC es o no
parte de un VP que contiene). El nodo de combinación de VC solo solicitará un único
VPI / VCI (ya que pueden fusionar todo el tráfico ascendente en un solo VC).
Los nodos de fusión transferirían las solicitudes que obtengan desde arriba,
Además, solicite un VPI / VCI para el tráfico que originan (si
apropiado).
3.27 . Túneles y Jerarquía
A veces, un enrutador Ru toma una acción explícita para causar un particular

paquete que se entregará a otro enrutador Rd, aunque Ru y Rd
no son enrutadores consecutivos en la ruta Hop-by-hop para ese paquete,
y Rd no es el destino final del paquete. Por ejemplo, esto
se puede hacer encapsulando el paquete dentro de un paquete de capa de red
cuya dirección de destino es la dirección de Rd en sí. Esto crea
un "túnel" de Ru a Rd. Nos referimos a cualquier paquete manejado como un
"Paquete tunelizado".
3.27.1 . Túnel enrutado Hop-by-Hop
Si un paquete Tunneled sigue la ruta Hop-by-hop de Ru a Rd,

decir que está en un "Túnel enrutado Hop-by-Hop" cuyo "transmitir
punto final "es Ru y cuyo" punto final receptor "es Rd.
3.27.2 . Túnel explícitamente enrutado
Si un paquete de túneles viaja de Ru a Rd por un camino diferente al

Ruta Hop-by-Hop, decimos que está en un "Túnel Explicitly Routed"
cuyo "punto final de transmisión" es Ru y cuyo "punto final de recepción" es Rd.
Por ejemplo, podríamos enviar un paquete a través de un Explicitly Routed
Túnel al encapsularlo en un paquete que se enruta desde la fuente.
3.27.3 . Túneles LSP
Es posible implementar un túnel como un LSP y usar la etiqueta

conmutación en lugar de encapsulación de capa de red para causar el paquete
viajar a través del túnel El túnel sería un LSP <R1, ...,
Rn>, donde R1 es el punto final de transmisión del túnel, y Rn es el
recibir punto final del túnel Esto se llama un "túnel LSP".
El conjunto de paquetes que se enviarán a través del túnel LSP

constituye un FEC, y cada LSR en el túnel debe asignar una etiqueta a
que FEC (es decir, debe asignar una etiqueta al túnel). Los criterios para
asignar un paquete particular a un túnel LSP es un asunto local en
el punto final de transmisión del túnel. Para poner un paquete en un túnel LSP,
el punto extremo de transmisión introduce una etiqueta para el túnel en la etiqueta
apila y envía el paquete etiquetado al siguiente salto en el túnel.
Si no es necesario que el punto final de recepción del túnel pueda

para determinar qué paquetes recibe a través del túnel, como
discutido anteriormente, la pila de etiquetas puede aparecer en el penúltimo
LSR en el túnel.
Un "túnel de LSP enrutado Hop-by-Hop" es un túnel que se implementa como
un LSP enrutado hop-by-hop entre el punto extremo transmisor y el
recibir punto final
Un "Túnel LSP Explicitly Routed" es un túnel LSP que también es un

Enrutado explícitamente LSP.
3.27.4 . Jerarquía: túneles LSP dentro de LSP
Considere un LSP <R1, R2, R3, R4>. Supongamos que R1 recibe

paquete sin etiqueta P, y empuja en su etiqueta apila la etiqueta para causar
seguir este camino, y que este es, de hecho, el camino Hop-by-hop.
Sin embargo, supongamos además que R2 y R3 no están directamente
conectados, pero son "vecinos" en virtud de ser los puntos finales de un
Túnel LSP. Entonces, la secuencia real de LSR atravesada por P es <R1,
R2, R21, R22, R23, R3, R4>.
Cuando P viaja de R1 a R2, tendrá una pila de etiquetas de profundidad 1.

R2, al encender la etiqueta, determina que P debe ingresar al túnel.
R2 primero reemplaza la etiqueta entrante con una etiqueta que tiene sentido
a R3. Luego empuja una nueva etiqueta. Esta etiqueta de nivel 2 tiene una
valor que es significativo para R21. El cambio se realiza en el nivel 2
etiqueta por R21, R22, R23. R23, que es el penúltimo salto en el
Túnel R2-R3, aparece la pila de etiquetas antes de reenviar el paquete a
R3. Cuando R3 ve el paquete P, P solo tiene una etiqueta de nivel 1, teniendo ahora
salió del túnel. Dado que R3 es el penúltimo salto en el nivel 1 de P
LSP, aparece la pila de etiquetas, y R4 recibe P sin etiqueta.
El mecanismo de pila de etiquetas permite que el túnel LSP anide a cualquier profundidad.
3.27.5 . Distribución de etiquetas Peering y jerarquía
Supongamos que el paquete P viaja a lo largo de un LSP de nivel 1 <R1, R2, R3, R4>,
y al pasar de R2 a R3 viaja a lo largo de un Nivel 2 LSP <R2, R21,
R22, R3>. Desde la perspectiva del Nivel 2 LSP, la etiqueta de R2
el par de distribución es R21. Desde la perspectiva del Nivel 1 LSP,
Los parceros de distribución de etiquetas de R2 son R1 y R3. Uno puede tener etiqueta
pares de distribución en cada capa de jerarquía. Veremos en
secciones 4.6 y 4.7 algunas formas de hacer uso de esta jerarquía. Nota
que en este ejemplo, R2 y R21 deben ser vecinos IGP, pero R2 y R3
Necesita no ser.
Cuando dos LSR son vecinos de IGP, nos referiremos a ellos como "locales".
pares de distribución de etiquetas ". Cuando dos LSR pueden ser distribución de
etiquetas
pares, pero no son vecinos de IGP, nos referiremos a ellos como "remotos"
pares de distribución de etiquetas ". En el ejemplo anterior, R2 y R21 son
pares de distribución de etiquetas locales, pero R2 y R3 son etiquetas remotas
pares de distribución.
La arquitectura MPLS admite dos formas de distribuir etiquetas en

diferentes capas de la jerarquía: Explotación explícita e implícita
Mirando.
Uno realiza distribución de etiquetas con la distribución de etiquetas local

entre pares enviando mensajes de protocolo de distribución de etiquetas que son
dirigido al par. Uno puede realizar la distribución de la etiqueta con uno
compañeros de distribución de etiquetas remotas en una de dos formas:
1. Peering explícito
En peering explícito, uno distribuye etiquetas a un par por

enviar mensajes de protocolo de distribución de etiquetas que son
dirigido al par, exactamente como uno haría por etiqueta local
pares de distribución. Esta técnica es más útil cuando el
número de pares de distribución remota de etiquetas es pequeño, o el
número de enlaces de etiquetas de nivel superior es grande, o el control remoto

Los pares de distribución de etiquetas se encuentran en distintas áreas de
enrutamiento o
dominios Por supuesto, uno necesita saber qué etiquetas
distribuir a qué pares; esto se trata en la sección 4.1.2 .
Ejemplos de uso de peering explícito se encuentran en secciones

4.2.1 y 4.6.
2. Penetración implícita
En Peering implícito, uno no envía distribución de etiquetas

mensajes de protocolo dirigidos a un compañero. Más bien,
para distribuir etiquetas de nivel superior a la etiqueta remota
pares de distribución, uno codifica una etiqueta de nivel superior como
atributo de una etiqueta de nivel inferior, y luego distribuye el
etiqueta de nivel inferior, junto con este atributo, a su local
compañeros de distribución de etiquetas. Los pares de distribución de etiquetas
locales
luego propague la información a su etiqueta local
pares de distribución. Este proceso continúa hasta el
la información llega al par remoto.
Esta técnica es más útil cuando el número de etiquetas remotas

los pares de distribución son grandes. Peering implícito no requiere
una malla de peering n-cuadrado para distribuir etiquetas en el control remoto
los pares de distribución de etiquetas porque la información está a cuestas
a través de la distribución local de etiquetas. Sin embargo,
el peering implícito requiere que los nodos intermedios se almacenen
información que pueden no interesarle directamente
Un ejemplo del uso de peering implícito se encuentra en la sección

4.3 .
3.28 . Transporte de protocolo de distribución de etiquetas
Se usa un protocolo de distribución de etiquetas entre los nodos en un MPLS

red para establecer y mantener los enlaces de etiquetas. Para poder
MPLS para operar correctamente, la información de distribución de etiquetas debe ser
transmitido de manera confiable, y los mensajes de protocolo de distribución de
etiquetas
perteneciente a un FEC particular necesita ser transmitido en secuencia.
El control de flujo también es deseable, al igual que la capacidad de llevar
múltiples mensajes de etiqueta en un solo datagrama.
Una forma de cumplir estos objetivos es utilizar TCP como el subyacente

transporte, como se hace en [ MPLS-LDP ] y [ MPLS-BGP ].

3.29 . ¿Por qué hay más de un protocolo de distribución de etiquetas?
Esta arquitectura no establece reglas duras y rápidas para elegir

qué protocolo de distribución de etiquetas usar en qué circunstancias.
Sin embargo, es posible señalar algunas de las consideraciones.
3.29.1 . BGP y LDP
En muchos escenarios, es deseable unir etiquetas a FEC que pueden

identificarse con rutas para hacer frente a los prefijos (ver sección 4.1 ). Si
hay un algoritmo de enrutamiento estándar ampliamente implementado que
distribuye esas rutas, se puede argumentar que la distribución de etiquetas es
mejor logrado mediante el uso de la distribución de etiquetas en el
distribución de las rutas mismas.
Por ejemplo, BGP distribuye tales rutas, y si un altavoz BGP necesita

para distribuir también etiquetas a sus pares BGP, usando BGP para hacer la etiqueta
distribución (ver [ MPLS-BGP ]) tiene una serie de ventajas. En
en particular, permite que los reflectores de ruta BGP distribuyan etiquetas,
proporcionando así una ventaja de escalabilidad significativa sobre el uso de LDP a
distribuir etiquetas entre pares BGP.
3.29.2 . Etiquetas para RSVP Flowspecs
Cuando RSVP se usa para configurar reservas de recursos para

flujos, puede ser deseable etiquetar los paquetes en esos flujos, por lo que
que RSVP filterspec no necesita aplicarse en cada salto. Eso
se puede argumentar que tener RSVP distribuir las etiquetas como parte de su
proceso de configuración de ruta / reserva es el método más eficiente de
distribución de etiquetas para este propósito.
3.29.3 . Etiquetas para los LSP explícitamente enrutados
En algunas aplicaciones de MPLS, particularmente aquellas relacionadas con el tráfico

ingeniería, es deseable configurar una ruta explícitamente enrutada,
de ingreso a egreso También es deseable aplicar el recurso
reservas a lo largo de ese camino.
Uno puede imaginar dos enfoques para esto:
- Comience con un protocolo existente que se usa para configurar

reservas de recursos, y ampliarlo para apoyar explícitamente
enrutamiento y distribución de etiquetas.
- Comience con un protocolo existente que se utiliza para la etiqueta

distribución, y ampliarlo para apoyar el enrutamiento explícito y
reservas de recursos.

El primer enfoque ha dado lugar al protocolo especificado en
[ MPLS-RSVP-TUNNELS ], el segundo al enfoque especificado en [MPLS-
CR-LDP].
3.30 . Multicast
Esta sección queda en estudio
4 . Algunas aplicaciones de MPLS
4.1 . MPLS y Hop by Hop Routed Traffic
Una serie de usos de MPLS requiere que los paquetes con una determinada etiqueta sean
reenviado a lo largo de la misma ruta enrutada hop-by-hop que se utilizaría
para reenviar un paquete con una dirección especificada en su capa de red
campo de dirección de destino.
4.1.1 . Etiquetas para los prefijos de direcciones
En general, el enrutador R determina el siguiente salto para el paquete P al encontrar

el prefijo de dirección X en su tabla de enrutamiento que es el partido más largo
para la dirección de destino de P. Es decir, los paquetes en un FEC determinado son
solo aquellos paquetes que coinciden con un prefijo de dirección dado en el enrutamiento
de R
mesa. En este caso, un FEC se puede identificar con un prefijo de dirección.
Tenga en cuenta que un paquete P puede asignarse a FEC F, y FEC F puede ser
identificado con el prefijo de dirección X, incluso si la dirección de destino de P
no coincide con X.
4.1.2 . Distribución de etiquetas para prefijos de dirección
4.1.2.1 . Distribuidores de distribución de etiquetas para un prefijo de dirección
Los LSRs R1 y R2 se consideran pares de distribución de etiquetas para

prefijo de dirección X si y solo si una de las siguientes condiciones
sostiene:
1. La ruta de R1 a X es una ruta que aprendió a través de un

instancia particular de un IGP particular, y R2 es un vecino
de R1 en ese caso de ese IGP
2. La ruta de R1 a X es una ruta que aprendieron algunos

instancia del algoritmo de enrutamiento A1, y esa ruta es
redistribuido en una instancia del algoritmo de enrutamiento A2 y R2
es un vecino de R1 en esa instancia de A2
Rosen, et al. Seguimiento de normas [Página 37]
3. R1 es el punto final de recepción de un túnel LSP que está dentro

otro LSP y R2 es un punto final de transmisión de ese túnel, y
R1 y R2 son participantes en una instancia común de un IGP, y
están en el mismo área de IGP (si el IGP en cuestión tiene áreas),
y la ruta de R1 a X se aprendió a través de esa instancia de IGP, o es
redistribuido por R1 en esa instancia de IGP
4. La ruta de R1 a X es una ruta que aprendió a través de BGP, y

R2 es un par BGP de R1
En general, estas reglas aseguran que si la ruta a un particular

el prefijo de dirección se distribuye a través de un IGP, la distribución de etiquetas
los pares para ese prefijo de dirección son los vecinos de IGP. Si la ruta a
un prefijo de dirección particular se distribuye a través de BGP, la etiqueta
los pares de distribución para ese prefijo de dirección son los pares BGP. En
otros casos de tunelización LSP, los puntos finales del túnel son etiqueta
pares de distribución.
4.1.2.2 . Distribución de etiquetas
Para usar MPLS para el reenvío de paquetes de acuerdo con el

ruta hop-by-hop correspondiente a cualquier prefijo de dirección, cada LSR DEBE:
1. unir una o más etiquetas a cada prefijo de dirección que aparece en

su tabla de enrutamiento;
2. para cada prefijo de dirección X, use una distribución de etiquetas

protocolo para distribuir la unión de una etiqueta a X a cada uno de
sus pares de distribución de etiquetas para X.
También hay una circunstancia en la que un LSR debe distribuir un

etiquetar vinculante para un prefijo de dirección, incluso si no es el LSR que
encuadernó esa etiqueta con ese prefijo de dirección:
3. Si R1 usa BGP para distribuir una ruta a X, nombrar a otra

LSR R2 como el siguiente salto de BGP a X, y si R1 sabe que R2 tiene
etiqueta asignada L a X, entonces R1 debe distribuir la unión
entre L y X a cualquier par BGP al que distribuye ese
ruta.
Estas reglas aseguran que las etiquetas correspondientes a los prefijos de direcciones
que corresponden a las rutas BGP se distribuyen a los vecinos IGP si
y solo si las rutas BGP se distribuyen en el IGP. De otra manera,
las etiquetas vinculadas a las rutas BGP se distribuyen solo a las otras BGP
altavoces.
Estas reglas están destinadas solo a indicar qué etiquetas deben ser
ser distribuido por un LSR dado a que otros LSR.
4.1.3 . Usar la ruta Hop by Hop como el LSP
Si la ruta de salto a salto que el paquete P necesita seguir es <R1, ...,

Rn>, entonces <R1, ..., Rn> puede ser un LSP siempre que:
1. hay un único prefijo de dirección X, tal que, para todo i,
1 <= i <n, X es la coincidencia más larga en la tabla de enrutamiento de Ri para
P
dirección de destino;
2. para todo i, 1 <i <n, Ri ha asignado una etiqueta a X y distribuido

esa etiqueta a R [i-1].
Tenga en cuenta que el LSP de un paquete puede extenderse solo hasta que encuentre un
enrutador
cuyas tablas de reenvío tienen un prefijo de dirección de coincidencia más largo para
la dirección de destino del paquete. En ese punto, el LSP debe terminar
y el mejor algoritmo de coincidencia debe realizarse nuevamente.
Supongamos, por ejemplo, ese paquete P, con dirección de destino

10.2.153.178 debe pasar de R1 a R2 a R3. Supongamos también que R2
anuncia el prefijo de la dirección 10.2 / 16 a R1, pero R3 anuncia
10.2.153 / 23, 10.2.154 / 23, y 10.2 / 16 a R2. Es decir, R2 es
anunciando una "ruta agregada" a R1. En esta situación, paquete P
se puede cambiar de etiqueta hasta que llegue a R2, pero dado que R2 ha realizado
agregación de ruta, debe ejecutar el mejor algoritmo de coincidencia para encontrar
FEC de P
4.1.4 . LSP Egress y LSP Proxy Egress
Un LSR R se considera un LSR "LSP Egress" para el prefijo de dirección X

si y solo si se cumple una de las siguientes condiciones:
1. R tiene una dirección Y, tal que X es el prefijo de dirección en R

tabla de enrutamiento que es la coincidencia más larga para Y, o
2. R contiene en sus tablas de enrutamiento uno o más prefijos de dirección Y

tal que X es una subcadena inicial adecuada de Y, pero R "LSP
saltos anteriores "para X no contienen ningún prefijo de dirección de ese tipo
Y; es decir, R es un "punto de desagregación" para el prefijo de dirección X.
Un LSR R1 se considera un LSR "LSP Proxy Egress" para la dirección

prefijo X si y solo si:
1. El siguiente salto de R1 para X es R2, y R1 y R2 no son etiqueta

pares de distribución con respecto a X (tal vez porque R2 lo hace
no es compatible con MPLS), o
2. R1 ha sido configurado para actuar como un LSP Proxy Egress para X
La definición de LSP permite que LSP Egress sea un nodo que

no es compatible con MPLS; en este caso, el penúltimo nodo en el LSP
es el Proxy Egress.
4.1.5 . La etiqueta NULL implícita
La etiqueta Implicit NULL es una etiqueta con semántica especial que

LSR puede vincularse a un prefijo de dirección. Si LSR Ru, consultando su ILM,
ve que el paquete etiquetado P debe enviarse junto a Rd, pero ese Rd
ha distribuido un enlace de IULL implícita a la correspondiente
prefijo de dirección, luego en lugar de reemplazar el valor de la etiqueta
al principio de la pila de etiquetas, Ru muestra la pila de etiquetas y luego la reenvía
el paquete resultante a Rd.
LSR Rd distribuye un enlace entre NULL implícito y una dirección
prefijo X a LSR Ru si y solo si:
1. las reglas de la Sección 4.1.2 indican que Rd distribuye a Ru a

etiquetado vinculante para X, y
2. Rd sabe que Ru puede soportar la etiqueta NULL implícita (es decir,

que puede reventar la pila de etiquetas), y
3. Rd es un LSP Egress (no proxy de salida) para X.
Esto hace que el penúltimo LSR en un LSP revele la pila de etiquetas.

Esto es bastante apropiado; si el LSP Egress es un MPLS Egress para X,
luego, si el penúltimo LSR no muestra la pila de etiquetas, el LSP
Egress deberá buscar la etiqueta, abrir la pila de etiquetas y luego
busca la siguiente etiqueta (o busca la dirección L3, si no hay más etiquetas)
están presentes). Al hacer que el penúltimo LSR revele la pila de etiquetas,
LSP Egress se guarda el trabajo de tener que buscar dos etiquetas en orden
para tomar su decisión de reenvío.
Sin embargo, si el penúltimo LSR es un interruptor ATM, es posible que no tenga el

capacidad para abrir la pila de etiquetas. Por lo tanto, un enlace de Implicit NULL
se puede distribuir solo a LSR que pueden soportar esa función.
Si el penúltimo LSR en un LSP para el prefijo de dirección X es un LSP Proxy

Egreso, actúa como si el LSP Egress hubiera distribuido un enlace
de NULL implícito para X.
4.1.6 . Opción: Asignación de etiqueta orientada a la salida
Hay situaciones en las que un LSP Ingress, Ri, sabe que los paquetes
de varios FEC diferentes deben seguir todos el mismo LSP, terminando
en, por ejemplo, LSP Egress Re. En este caso, se puede lograr un enrutamiento adecuado
utilizando una sola etiqueta para todos esos FEC; no es necesario

tener una etiqueta distinta para cada FEC. Si (y solo si) lo siguiente
condiciones mantener:
1. la dirección de LSR Re se encuentra en la tabla de enrutamiento como "host

ruta ", y
2. hay alguna forma de que Ri determine que Re es la salida de LSP

para todos los paquetes en un conjunto particular de FEC
Entonces Ri puede unir una sola etiqueta a todos los FECS en el conjunto. Esto es
conocido como "Asignación de etiqueta orientada a la salida".
¿Cómo puede LSR Ri determinar que un LSR Re es el LSP Egress para todos
paquetes en un FEC en particular? Hay una serie de formas posibles:
- Si la red ejecuta un algoritmo de enrutamiento de estado de enlace, y

todos los nodos en el área admiten MPLS, luego el algoritmo de enrutamiento
proporciona Ri con suficiente información para determinar los enrutadores
a través del cual los paquetes en ese FEC deben abandonar el dominio de
enrutamiento
o área
- Si la red ejecuta BGP, Ri puede determinar que

los paquetes en un FEC particular deben abandonar la red a través de
router particular que es el "BGP Next Hop" para ese FEC.
- Es posible utilizar el protocolo de distribución de etiquetas para aprobar

información sobre qué prefijos de dirección están "adjuntos" a
que egreso LSRs. Este método tiene la ventaja de no
dependiendo de la presencia del enrutamiento de estado del enlace.
Si se utiliza la asignación de etiquetas orientada a la salida, la cantidad de etiquetas

que necesitan ser apoyados en toda la red puede ser grande
reducido. Esto puede ser significativo si uno está usando conmutación heredada
hardware para hacer MPLS, y el hardware de conmutación puede admitir solo una
número limitado de etiquetas.
Un posible enfoque sería configurar la red para usar

asignación de etiqueta orientada a la salida de forma predeterminada, pero para
configurar
LSR particulares para NO usar la asignación de etiqueta orientada a egreso para uno
o más de los prefijos de direcciones para los cuales es una salida LSP. Nosotros
imponer la siguiente regla:
- Si un LSR particular NO es un LSP Egreso para algún conjunto de

prefijos de direcciones, entonces debe asignar etiquetas a la dirección
prefijos de la misma manera que lo hace su LSP siguiente salto para
esos prefijos de dirección. Es decir, supongamos que Rd es el LSP de Ru siguiente
salto para los prefijos de dirección X1 y X2. Si Rd asigna el mismo

etiqueta a X1 y X2, Ru también debería. Si Rd asigna diferente
etiquetas a X1 y X2, entonces Ru también debería hacerlo.
Por ejemplo, supongamos que uno quiere hacer una etiqueta orientada a la salida
asignación predeterminada, pero para asignar etiquetas distintas a las
prefijos de direcciones para los cuales hay múltiples salidas posibles de LSP
(es decir, para aquellos prefijos de direcciones que son multi-homed.) Uno puede
configurar todos los LSR para utilizar la asignación de etiquetas orientadas a la
salida, y luego
configurar un puñado de LSR para asignar etiquetas distintas a las
prefijos de direcciones que son multi-homed. Para un particular multi-hogar
prefijo de dirección X, uno solo necesitaría configurar esto en LSR que
son LSP Egresses o LSP Proxy Egresses para X.
Es importante tener en cuenta que si Ru y Rd son LSR adyacentes en un LSP

para X1 y X2, el reenvío seguirá realizándose correctamente si Ru asigna
etiquetas distintas a X1 y X2, mientras que Rd asigna una sola etiqueta a la
ambos. Esto solo significa que R1 mapeará diferentes entradas
etiquetas a la misma etiqueta saliente, una ocurrencia ordinaria.
Del mismo modo, si Rd asigna etiquetas distintas a X1 y X2, pero Ru asigna

a ambos, la etiqueta correspondiente a la dirección de su LSP
Egreso o Proxy Egress, el reenvío seguirá realizándose correctamente. Ru
simplemente asignará la etiqueta entrante a la etiqueta que Rd ha asignado
a la dirección de ese LSP Egress.
4.2 . MPLS y LSP explícitamente enrutados
Hay una serie de razones por las cuales puede ser deseable usar explícitamente
enrutamiento en lugar de enrutamiento hop by hop. Por ejemplo, esto permite
rutas basadas en políticas administrativas, y permite las rutas
que los LSP tienen que ser cuidadosamente diseñados para permitir la ingeniería de
tráfico
[ MPLS-TRFENG ].
4.2.1 . Túneles LSP explícitamente enrutados
En algunas situaciones, los administradores de red pueden desear reenviar

ciertas clases de tráfico a lo largo de ciertos caminos preespecificados, donde
estas rutas difieren de la ruta Hop-by-hop que el tráfico
ordinariamente sigue. Esto se puede hacer en apoyo del enrutamiento de políticas, o
en apoyo de la ingeniería de tráfico. La ruta explícita puede ser una
configurado, o puede determinarse dinámicamente de alguna manera,
por ejemplo, mediante el enrutamiento basado en restricciones.
MPLS permite que esto se realice fácilmente por medio de LSP Explicitly Routed
Túneles Todo lo que se necesita es:
1. Un medio para seleccionar los paquetes que se enviarán al

Túnel LSP explícitamente enrutado;
2. Un medio para configurar el túnel LSP Explicitly Routed;
3. Un medio para asegurar que los paquetes enviados al Túnel no

bucle desde el punto final de recepción hasta el punto final de transmisión.
Si el punto final de transmisión del túnel desea poner un paquete etiquetado

en el túnel, primero debe reemplazar el valor de la etiqueta en la parte superior de
la pila con un valor de etiqueta que se distribuyó por el
punto final de recepción del túnel. Luego debe presionar en la etiqueta que
corresponde al túnel en sí, según lo distribuido por el siguiente
saltar a lo largo del túnel. Para permitir esto, los puntos finales del túnel deben
ser
pares explícitos de distribución de etiquetas. Las etiquetas que necesitan para
intercambio no son de interés para los LSR a lo largo del túnel.
4.3 . Pilas de etiquetas y Peering implícito
Supongamos que un LSR Re particular es una salida de proxy LSP para 10 direcciones
prefijos, y llega a cada prefijo de dirección a través de un
interfaz.
Se podría asignar una sola etiqueta a los 10 prefijos de direcciones. Entonces Re

es una salida LSP para los 10 prefijos de direcciones. Esto asegura que
los paquetes para los 10 prefijos de direcciones se entregan a Re. Sin embargo, Re
tendría que buscar la dirección de la capa de red de cada uno
paquete para elegir la interfaz adecuada para enviar el paquete.
Alternativamente, uno podría asignar una etiqueta distinta a cada interfaz.

Entonces Re es una salida de proxy LSP para los 10 prefijos de dirección. Esta
elimina la necesidad de que Re busque las direcciones de la capa de red en
orden para reenviar los paquetes. Sin embargo, puede resultar en el uso de un
gran cantidad de etiquetas
Una alternativa sería vincular los 10 prefijos de direcciones al mismo

etiqueta de nivel 1 (que también está vinculada a la dirección del propio LSR),
y luego vincular cada prefijo de dirección a una etiqueta distinta de nivel 2.
La etiqueta de nivel 2 se trataría como un atributo del nivel 1
unión de etiquetas, que llamamos "Atributo de pila". Nosotros imponemos el
siguiendo las reglas:
- Cuando LSR Ru inicialmente etiqueta un paquete hasta ahora sin etiqueta, si

la coincidencia más larga para la dirección de destino del paquete es X,
y el siguiente salto de LS de Ru para X es Rd, y Rd se ha distribuido a Ru
una unión de la etiqueta L1 a X, junto con un atributo de pila de L2,
entonces

1. Ru debe presionar L2 y luego L1 en la pila de etiquetas del paquete,

y luego reenviar el paquete a Rd;
2. Cuando Ru distribuye enlaces de etiquetas para X a su etiqueta

pares de distribución, debe incluir L2 como la pila
atributo.
3. Siempre que el atributo de pila cambie (posiblemente como resultado

de un cambio en el siguiente salto de Ru's LSP para X), Ru debe distribuir
el nuevo atributo de pila.
Tenga en cuenta que aunque el valor de la etiqueta vinculado a X puede ser diferente
en
cada salto a lo largo del LSP, se pasa el valor del atributo de la pila
sin cambios, y se establece mediante la salida del proxy LSP.
Por lo tanto, la salida proxy de LSP para X se convierte en un "par implícito" con cada
otro LSR en el área o dominio de enrutamiento. En este caso, explícito
el peering sería demasiado difícil de manejar, porque el número de compañeros
ser demasiado grande
4.4 . MPLS y enrutamiento de múltiples rutas
Si un LSR admite múltiples rutas para un flujo en particular, entonces

puede asignar múltiples etiquetas a la secuencia, una para cada ruta. Así
la recepción de un segundo enlace de etiqueta de un vecino en particular
para un prefijo de dirección particular debe entenderse como que
cualquiera de las etiquetas se puede usar para representar ese prefijo de dirección.
Si hay múltiples enlaces de etiquetas para un prefijo de dirección particular,

especificado, pueden tener atributos distintos.
4.5 . Árboles LSP como entidades multipunto a punto
Considere el caso de los paquetes P1 y P2, cada uno de los cuales tiene un
dirección de destino cuyo partido más largo, a lo largo de un particular
dominio de enrutamiento, es el prefijo de dirección X. Supongamos que el salto por
salto
ruta para P1 es <R1, R2, R3>, y la ruta de salto por salto para P2 es <R4,
R2, R3>. Supongamos que R3 une la etiqueta L3 a X y distribuye
esta unión a R2. R2 une la etiqueta L2 a X, y distribuye esto
vinculante para R1 y R4. Cuando R2 recibe el paquete P1, su entrada
la etiqueta será L2. R2 sobrescribirá L2 con L3, y envía P1 a R3.
Cuando R2 recibe el paquete P2, su etiqueta entrante también será L2. R2
de nuevo sobrescribe L2 con L3 y envía P2 a R3.
Tenga en cuenta que cuando P1 y P2 viajan de R2 a R3, llevan

la misma etiqueta, y en lo que respecta a MPLS, no pueden ser
distinguido. Por lo tanto, en lugar de hablar de dos LSP distintos, <R1,
R2, R3> y <R4, R2, R3>, podríamos hablar de un solo "Multipunto para
Point LSP Tree ", que podríamos denotar como <{R1, R4}, R2, R3>.
Esto crea una dificultad cuando intentamos usar un cajero automático convencional
conmuta como LSR. Como los conmutadores ATM convencionales no son compatibles
conexiones multipunto-a-punto, debe haber procedimientos para asegurar
que cada LSP se realiza como un VC punto a punto. Sin embargo, si ATM
Los switches que soportan VCs multipunto a punto están en uso, entonces
los LSP se pueden realizar de forma más eficiente como VCs multipunto a punto.
Alternativamente, si la Codificación multipunto SVP ( sección 3.25.2 ) puede ser
utilizado, los LSP se pueden realizar como SVP multipunto a punto.
4.6 . Túnel de LSP entre enrutadores de borde BGP
Considere el caso de un Sistema Autónomo, A, que transporta tránsito

tráfico entre otros Sistemas Autónomos. El Sistema Autónomo A lo hará
tener un número de BGP Border Routers, y una malla de conexiones BGP
entre ellos, sobre qué rutas BGP se distribuyen. En muchos de tales
casos, es deseable evitar distribuir las rutas BGP a
enrutadores que no son enrutadores de borde BGP. Si esto puede evitarse,
la "carga de distribución de ruta" en esos enrutadores es significativamente
reducido. Sin embargo, debe haber algunos medios para garantizar que
el tráfico de tránsito será entregado desde el enrutador fronterizo al enrutador
fronterizo
por los enrutadores interiores.
Esto puede hacerse fácilmente por medio de túneles LSP. Supongamos que BGP
las rutas se distribuyen solo a BGP Border Routers, y no a
enrutadores interiores que se encuentran a lo largo de la ruta Hop-by-hop from Border
Enrutador a enrutador de frontera. Los túneles LSP se pueden usar de la siguiente
manera:
1. Cada enrutador BGP Border distribuye, a cada otro borde BGP

Enrutador en el mismo Sistema Autónomo, una etiqueta para cada dirección
prefijo que distribuye a ese enrutador a través de BGP.
2. El IGP para el Sistema Autónomo mantiene una ruta de host para

cada enrutador de borde BGP. Cada enrutador interior distribuye su
etiquetas para estas rutas de host a cada uno de sus vecinos IGP.
3. Supongamos que:
a) BGP Border Router B1 recibe un paquete sin etiqueta P,
b) el prefijo de dirección X en la tabla de enrutamiento de B1 es el más largo

para la dirección de destino de P,
c) la ruta a X es una ruta BGP,
d) el BGP Next Hop para X es B2,
e) B2 ha vinculado la etiqueta L1 a X, y ha distribuido esta unión

a B1,
f) el siguiente salto de IGP para la dirección de B2 es I1,
g) la dirección de B2 está en las tablas de enrutamiento IGP de B1 e I1 como

una ruta de host, y
h) I1 ha vinculado la etiqueta L2 a la dirección de B2, y distribuido

esta unión a B1.
Luego, antes de enviar el paquete P a I1, B1 debe crear una etiqueta

apilar para P, luego presione la etiqueta L1, y luego presione la etiqueta L2.
4. Supongamos que BGP Border Router B1 recibe un paquete etiquetado P,

donde la etiqueta en la parte superior de la pila de etiquetas corresponde a una
prefijo de dirección, X, para el cual la ruta es una ruta BGP, y que
las condiciones 3b, 3c, 3d y 3e se mantienen todas. Entonces antes de enviar
el paquete P a I1, B1 debe reemplazar la etiqueta en la parte superior del
Apile la pila con L1, y luego presione la etiqueta L2.
Con estos procedimientos, un paquete P dado sigue un LSP de nivel 1, todos de
cuyos miembros son BGP Border Routers, y entre cada par de BGP
Border Routers en el nivel 1 LSP, sigue un nivel 2 LSP.
Estos procedimientos crean efectivamente un túnel LSP enrutado Hop-by-Hop

entre los enrutadores fronterizos BGP.
Dado que los enrutadores de borde BGP están intercambiando enlaces de etiquetas para
prefijos de direcciones que ni siquiera conocen el enrutamiento IGP, el BGP
los enrutadores deberían convertirse en pares explícitos de distribución de etiquetas
con cada
otro.
A veces es posible crear túneles LSP enrutados hop-by-hop

entre dos enrutadores de borde BGP, incluso si no están en el mismo
Sistema autónomo. Supongamos, por ejemplo, que B1 y B2 están en AS 1.
Supongamos que B3 es un vecino EBGP de B2 y está en AS2. Finalmente,
supongamos que B2 y B3 están en alguna red que es común a ambos
Sistemas autónomos (una "zona desmilitarizada"). En este caso, un LSP
túnel se puede configurar directamente entre B1 y B3 de la siguiente manera:
- B3 distribuye rutas a B2 (usando EBGP), asignando opcionalmente

etiquetas para abordar prefijos;
- B2 redistribuye esas rutas a B1 (usando IBGP), lo que indica

que el siguiente salto de BGP para cada una de esas rutas es B3. Si B3 tiene
Etiquetas asignadas para los prefijos de direcciones, B2 pasa estas etiquetas
a lo largo, sin cambios, a B1.
- El IGP de AS1 tiene una ruta de host para B3.
4.7 . Otros usos de los túneles LSP enrutados Hop-by-Hop
El uso de túneles LSP enrutados hop-by-hop no está restringido a túneles

entre BGP Next Hops. Cualquier situación en la que uno podría de otra manera
han utilizado un túnel de encapsulación es aquel en el que es apropiado
utilizar un túnel LSP enrutado Hop-by-Hop. En lugar de encapsular el
paquete con un nuevo encabezado cuya dirección de destino es la dirección de
el punto final de recepción del túnel, la etiqueta correspondiente a la dirección
prefijo que es la coincidencia más larga para la dirección del túnel
el punto final de recepción se inserta en la pila de etiquetas del paquete. El paquete
que se envía al túnel puede o no estar etiquetado.
Si el punto final de transmisión del túnel desea poner un paquete etiquetado

en el túnel, primero debe reemplazar el valor de la etiqueta en la parte superior de
la pila con un valor de etiqueta que se distribuyó por el
punto final de recepción del túnel. Luego debe presionar en la etiqueta que
corresponde al túnel en sí, según lo distribuido por el siguiente
saltar a lo largo del túnel. Para permitir esto, los puntos finales del túnel deben
ser
pares explícitos de distribución de etiquetas. Las etiquetas que necesitan para
intercambio no son de interés para los LSR a lo largo del túnel.
4.8 . MPLS y Multicast
El enrutamiento de multidifusión procede al construir árboles de multidifusión. El

árbol
a lo largo del cual un paquete de multidifusión en particular debe ser enviado depende
en general, en la dirección de origen del paquete y su destino
dirección. Cuando un LSR particular es un nodo en un particular
árbol de multidifusión, vincula una etiqueta a ese árbol. Luego distribuye
ese enlace a su padre en el árbol de multidifusión. (Si el nodo en
la pregunta está en una LAN, y tiene hermanos en esa LAN, también debe
distribuir el enlace a sus hermanos. Esto le permite al padre
utilizar un valor de etiqueta única cuando multidifusión a todos los niños en el
LAN)
Cuando llega un paquete etiquetado de multidifusión, el NHLFE correspondiente a

la etiqueta indica el conjunto de interfaces de salida para ese paquete, como
así como la etiqueta saliente. Si la misma técnica de codificación de etiqueta es
utilizado en todas las interfaces salientes, se puede enviar el mismo paquete
a todos los niños.
5 . Procedimientos de distribución de etiquetas (Hop-by-Hop)
En esta sección, consideramos solo los enlaces de etiquetas que se usan para
tráfico para etiquetar cambiado a lo largo de su ruta enrutada salto por salto. En
En estos casos, la etiqueta en cuestión corresponderá a una dirección
prefijo en la tabla de enrutamiento.
5.1 . Los procedimientos para publicitar y usar etiquetas
Hay varios procedimientos diferentes que se pueden usar para

distribuir enlaces de etiquetas. Algunos son ejecutados por el LSR aguas abajo,
y algunos por el LSR aguas arriba.
El LSR indirecto debe realizar:
- El procedimiento de distribución, y
- El Procedimiento de Retiro.
El LSR ascendente debe realizar:
- El procedimiento de solicitud, y
- el procedimiento no disponible, y
- el procedimiento de liberación, y
- el procedimiento Label Use.
La arquitectura MPLS admite varias variantes de cada procedimiento.
Sin embargo, la arquitectura MPLS no admite todos los posibles

combinaciones de todas las variantes posibles. El conjunto de compatibles
combinaciones se describirán en la sección 5.2 , donde
la interoperabilidad entre diferentes combinaciones también será
discutido.
5.1.1 . Downstream LSR: Procedimiento de distribución
El Procedimiento de distribución es utilizado por un LSR indirecto para determinar

cuando debería distribuir un enlace de etiqueta para una dirección particular
prefijo a sus pares de distribución de etiquetas. La arquitectura admite
cuatro diferentes procedimientos de distribución.
Independientemente del procedimiento particular que se use, si una etiqueta
el enlace para un prefijo de dirección particular ha sido distribuido por un
aguas abajo LSR Rd a aguas arriba LSR Ru, y si en algún momento el
atributos (como se define arriba) de ese cambio de enlace, entonces Rd debe
informar a Ru de los nuevos atributos.
Si un LSR mantiene múltiples rutas a una dirección particular

prefijo, es un asunto local si ese LSR une múltiples
etiquetas al prefijo de dirección (una por ruta) y, por lo tanto, distribuye
enlaces múltiples
5.1.1.1 . PushUnconditional
Deje Rd ser un LSR. Suponer que:
1. X es un prefijo de dirección en la tabla de enrutamiento de Rd
2. Ru es un par de distribución de etiquetas de Rd con respecto a X
Siempre que estas condiciones se cumplan, Rd debe unir una etiqueta a X y

distribuir ese enlace a Ru. Es la responsabilidad de Rd a
realizar un seguimiento de las consolidaciones que ha distribuido a Ru, y
asegúrese de que Ru siempre tenga estos enlaces.
Este procedimiento sería utilizado por los LSR que realizan acciones no solicitadas
asignación de etiquetas aguas abajo en el modo de control LSP independiente.
5.1.1.2 . PushConditional
3. Rd es un LSP Egress o un LSP Proxy Egress para X, o

El próximo salto de L3 de Rd para X es Rn, donde Rn es distinto de Ru, y
Rn ha vinculado una etiqueta a X y distribuido ese enlace a Rd.
Entonces, tan pronto como estas condiciones se cumplan, Rd debe unir una etiqueta a
X y distribuir ese enlace a Ru.
Mientras que PushUnconditional causa la distribución de enlaces de etiquetas

para todos los prefijos de direcciones en la tabla de enrutamiento, PushConditional
causa
la distribución de enlaces de etiquetas solo para aquellos prefijos de direcciones
para lo cual uno ha recibido enlaces de etiquetas del siguiente salto de LSP, o
para lo cual uno no tiene un L3 siguiente capaz de MPLS.
Este procedimiento sería utilizado por los LSR que realizan acciones no solicitadas
asignación de etiquetas aguas abajo en el modo de control LSP ordenado.
5.1.1.3 . PulledUnconditional
3. Ru ha solicitado explícitamente que Rd una etiqueta a X y

distribuir el enlace a Ru
Entonces Rd debe unir una etiqueta a X y distribuir ese enlace a Ru.

Tenga en cuenta que si X no está en la tabla de enrutamiento de Rd, o si Rd no es una
etiqueta
par de distribución de Ru con respecto a X, entonces Rd debe informar a Ru
que no puede proporcionar un enlace en este momento.
Si Rd ya ha distribuido un enlace para el prefijo de dirección X a Ru,

y recibe una nueva solicitud de Ru para un enlace para la dirección
prefijo X, enlazará una segunda etiqueta y distribuirá la nueva unión
a Ru. El primer enlace de etiqueta permanece vigente.
Este procedimiento sería utilizado por los LSR que realizan flujo descendente según
demanda
distribución de etiquetas usando el modo de control LSP independiente.
5.1.1.4 . PulledConditional
3. Ru ha solicitado explícitamente que Rd una etiqueta a X y

distribuir el enlace a Ru
4. Rd es un LSP Egress o un LSP Proxy Egress para X, o

El próximo salto de L3 de Rd para X es Rn, donde Rn es distinto de Ru, y
Rn ha vinculado una etiqueta a X y distribuido ese enlace a Rd
Entonces, tan pronto como estas condiciones se cumplan, Rd debe unir una etiqueta a
X y distribuir ese enlace a Ru. Tenga en cuenta que si X no está en Rd
la tabla de enrutamiento y un enlace para X no se pueden obtener a través del próximo
salto de Rd
para X, o si Rd no es un par de distribución de etiquetas de Ru con respecto
a X, entonces Rd debe informar a Ru que no puede proporcionar un enlace en este
hora.
Sin embargo, si la única condición que falla es que Rn no tiene

sin embargo, proporcionó una etiqueta a Rd, entonces Rd debe diferir cualquier respuesta
a Ru
hasta el momento en que haya recibido un enlace de Rn.
Si Rd ha distribuido un enlace de etiqueta para el prefijo de dirección X a Ru, y

en algún momento posterior, cualquier atributo del enlace vinculante cambia, luego
Rd debe redistribuir el enlace de etiqueta a Ru, con el nuevo atributo.
Debe hacer esto a pesar de que Ru no emite una nueva Solicitud.

Este procedimiento sería utilizado por los LSR que están realizando aguas abajo-
asignación de etiquetas a petición en el modo de control LSP ordenado.
En la sección 5.2 , discutiremos cómo elegir el particular

procedimiento que se utilizará en un momento dado, y cómo garantizar
interoperabilidad entre los LSR que eligen diferentes procedimientos.
5.1.2 . Upstream LSR: procedimiento de solicitud
El procedimiento de solicitud es utilizado por el LSR ascendente para una dirección

prefijo para determinar cuándo solicitar explícitamente que el flujo descendente
LSR une una etiqueta a ese prefijo y distribuye el enlace. Ahí
hay tres procedimientos posibles que se pueden usar.
5.1.2.1 . SolicitudNunca
Nunca haga una solicitud. Esto es útil si el LSR indirecto usa el

Procedimiento PushConditional o el procedimiento PushUnconditional, pero es
no es útil si el LSR indirecto utiliza el PulledUnconditional
procedimiento o los procedimientos PulledConditional.
Este procedimiento sería utilizado por un LSR cuando no se solicitó aguas abajo
la distribución de etiqueta y el modo de retención de etiqueta liberal se están
utilizando.
5.1.2.2 . SolicitudcuandoNecesita
Realice una solicitud siempre que el siguiente L3 salte al prefijo de dirección

cambios, o cuando se aprende un nuevo prefijo de dirección, y uno no
ya tiene una etiqueta vinculante de ese próximo salto para la dirección dada
prefijo.
Este procedimiento sería utilizado por un LSR cada vez que la etiqueta conservadora
El modo de retención se está utilizando.
5.1.2.3 . RequestOnRequest
Emite una solicitud cada vez que se recibe una solicitud, además de
emitir una solicitud cuando sea necesario (como se describe en la sección 5.1.2.2 ).
Si
Ru no puede ser un ingreso LSP, puede emitir una solicitud
solo cuando recibe una solicitud desde la parte superior.
Si Rd recibe dicha solicitud de Ru, para un prefijo de dirección para

que Rd ya ha distribuido una etiqueta Ru, Rd asignará un nuevo
etiqueta (distinta), únela a X y distribuya esa unión.
(Si Rd puede distribuir este enlace a Ru inmediatamente o no
depende del procedimiento de distribución utilizado).

Este procedimiento sería utilizado por un LSR que está haciendo downstream-on-
Exigir la distribución de etiquetas, pero no está fusionando la etiqueta, por ejemplo,
una
ATM-LSR que no es capaz de combinar VC.
5.1.3 . Upstream LSR: procedimiento no disponible
Si Ru y Rd son, respectivamente, etiqueta de aguas arriba y aguas abajo

compañeros de distribución para el prefijo de dirección X, y Rd es el siguiente salto
de Ru's L3
para X, y Ru solicita un enlace para X de Rd, pero Rd responde que
no puede proporcionar un enlace en este momento, porque no tiene próximo salto
para X, entonces el procedimiento NotAvailable determina cómo responde Ru.
Hay dos posibles procedimientos que rigen el comportamiento de Ru:
5.1.3.1 . RequestRetry
Ru debería emitir la solicitud nuevamente en otro momento. Eso es el

solicitante es responsable de intentar nuevamente más tarde para obtener el
Unión. Este procedimiento se usaría cuando se descender a pedido
se usa la distribución de etiquetas.
5.1.3.2 . SolicitudNoRetry
Ru nunca debe volver a emitir la solicitud, sino que asumirá que Rd

proporcione el enlace automáticamente cuando esté disponible. Esto es
útil si Rd utiliza el procedimiento PushUnconditional o el
Procedimiento PushConditional, es decir, si la etiqueta aguas abajo no solicitada
distribución se usa.
Tenga en cuenta que si Rd responde que no puede proporcionar un enlace a Ru,

debido a alguna condición de error, en lugar de porque Rd no tiene siguiente
hop, el comportamiento de Ru se regirá por la recuperación de errores
condiciones del protocolo de distribución de etiquetas, en lugar de
Procedimiento no disponible.
5.1.4 . Upstream LSR: procedimiento de liberación
Supongamos que Rd es un LSR que ha unido una etiqueta al prefijo de dirección

X, y ha distribuido ese enlace a LSR Ru. Si Rd no sucede
ser el siguiente salto de Ru L3 para el prefijo de dirección X, o ha dejado de ser el
de Ru
L3 próximo salto para el prefijo de dirección X, luego Ru no usará el
etiqueta. El procedimiento de liberación determina cómo actúa Ru en este caso.
Hay dos posibles procedimientos que rigen el comportamiento de Ru:
5.1.4.1 . ReleaseOnChange
Ru debería liberar el enlace e informar a Rd que ya lo hizo.

Este procedimiento se usaría para implementar la etiqueta conservadora
Modo de retención.
5.1.4.2 . NoReleaseOnChange
Ru debería mantener el enlace, para que pueda volver a usarlo

inmediatamente si Rd más tarde se convierte en el siguiente salto de Ru para X. Esto
El procedimiento se usaría para implementar el Modo de retención de etiqueta liberal.
5.1.5 . Upstream LSR: labelUse Procedimiento
Supongamos que Ru es un LSR que ha recibido la etiqueta L vinculante para la dirección

prefijo X de LSR Rd, y Ru está aguas arriba de Rd con respecto a X, y
de hecho Rd es el siguiente salto de Ru's L3 para X.
Ru hará uso del enlace si Rd es el siguiente salto de Ru L3 para X. Si,

en el momento en que Ru recibe el enlace, Rd no es el próximo salto de Ru L3
para X, Ru no hace ningún uso del enlace en ese momento. Ru puede
sin embargo, comience a usar el enlace en algún momento posterior, si Rd se convierte
El siguiente salto de Ru's L3 para X.
El procedimiento LabelUse determina cómo Ru hace uso de Rd's

Unión.
Hay dos procedimientos que Ru puede usar:
5.1.5.1 . UseImmediate
Ru puede poner el enlace en uso de inmediato. En cualquier momento cuando Ru tiene

un enlace para X desde Rd, y Rd es el siguiente salto de Ru's L3 para X, Rd
también se el LSP de Ru para el siguiente salto para X. Este procedimiento se usa cuando
el ciclo
la detección no está en uso.
5.1.5.2 . UseIfLoopNotDetected
Este procedimiento es el mismo que UseImmediate, a menos que Ru haya detectado un

loop en el LSP. Si se ha detectado un ciclo, Ru descontinuará
el uso de la etiqueta L para reenviar paquetes a Rd.
Este procedimiento se usa cuando la detección de bucle está en uso.
Esto continuará hasta que el siguiente salto para X cambie, o hasta que el
loop ya no se detecta.
5.1.6 . LSR aguas abajo: procedimiento de retirada
En este caso, solo hay un solo procedimiento.
Cuando LSR Rd decide romper la unión entre la etiqueta L y la dirección

prefijo X, entonces esta desvinculación se debe distribuir a todos los LSR a
que el enlace fue distribuido.
Se requiere que la desvinculación de L de X se distribuya por Rd a

un LSR Ru antes de Rd distribuye a Ru cualquier nuevo enlace de L a cualquier
otro prefijo de dirección Y, donde X! = Y. Si Ru conociera el nuevo
unión de L a Y antes de conocer la desvinculación de L de X, y
si los paquetes que coinciden con X e Y fueron enviados por Ru a Rd, entonces por
un período de tiempo, Ru etiquetaría ambos paquetes que coinciden con X y paquetes
haciendo coincidir Y con la etiqueta L.
La distribución y el retiro de las etiquetas se realiza mediante una etiqueta

protocolo de distribución. Todos los protocolos de distribución de etiquetas requieren
que
una adyacencia de distribución de etiqueta se establecerá entre dos etiquetas
pares de distribución (excepto pares implícitos). Si LSR R1 tiene una etiqueta
adyacencia de distribución a LSR R2, y ha recibido enlaces de etiqueta
de LSR R2 a través de esa adyacencia, entonces si la adyacencia es derribada por
cualquiera de los pares (ya sea como resultado de una falla o como una cuestión de
normalidad)
operación), todas las consolidaciones recibidas sobre esa adyacencia deben ser
considerado como retirado.
Mientras la adyacencia de distribución de etiquetas relevante permanezca en

lugar, las etiquetas que se retiran deben retirarse siempre
explícitamente. Si una segunda etiqueta está vinculada a un prefijo de dirección, el
El resultado no es retirar implícitamente la primera etiqueta, sino unir
ambas etiquetas; esto es necesario para admitir el enrutamiento de múltiples rutas. Si
un
el segundo prefijo de dirección está vinculado a una etiqueta, el resultado no es
Retirar implícitamente el enlace de esa etiqueta a la primera dirección
prefijo, pero para usar esa etiqueta para ambos prefijos de dirección.
5.2 . Esquemas MPLS: Combinaciones de procedimientos admitidos
Considere dos LSR, Ru y Rd, que son pares de distribución de etiquetas con
con respecto a un conjunto de prefijos de direcciones, donde Ru es la corriente
ascendente
peer y Rd es el par descendente.
El esquema MPLS que rige la interacción de Ru y Rd puede ser

se describe como un quíntuple de procedimientos: <Procedimiento de distribución,
Procedimiento de solicitud, procedimiento no disponible, procedimiento de liberación
labelUse Procedimiento>. (Dado que solo hay un Procedimiento de Retiro,
no es necesario mencionarlo). Un "*" que aparece en una de las posiciones es
comodín, lo que significa que cualquier procedimiento en esa categoría puede ser
presente; un "N / A" que aparece en una posición particular indica que
no se necesita ningún procedimiento en esa categoría.
Solo los esquemas MPLS que se especifican a continuación son compatibles con el
Arquitectura MPLS. Se pueden agregar otros esquemas en el futuro, si
necesidad de ellos se muestra.
5.2.1 . Esquemas para LSR que admiten fusión de etiquetas

Si Ru y Rd son pares de distribución de etiquetas, y ambas admiten etiqueta
fusión, se debe utilizar uno de los siguientes esquemas:
1. <PushUnconditional, RequestNever, N / A, NoReleaseOnChange,

UseImmediate>
Esta es la distribución de etiquetas aguas abajo no solicitada con

control independiente, modo de retención liberal de etiquetas y ningún bucle
detección.
2. <PushUnconditional, RequestNever, N / A, NoReleaseOnChange,

UseIfLoopNotDetected>
Esta es la distribución de etiquetas aguas abajo no solicitada con

control independiente, retención liberal de etiquetas y bucle
detección.
3. <PushConditional, RequestWhenNeeded, RequestNoRetry,

ReleaseOnChange, *>
Esta es la distribución de etiquetas aguas abajo no solicitada con pedido

control (desde la salida) y retención de etiqueta conservadora
modo. La detección de bucle es opcional.
4. <PushConditional, RequestNever, N / A, NoReleaseOnChange, *>
Esta es la distribución de etiquetas aguas abajo no solicitada con pedido

control (desde la salida) y modo de retención de etiqueta liberal.
La detección de bucle es opcional.
5. <PulledConditional, RequestWhenNeeded, RequestRetry,

ReleaseOnChange, *>
Esta es la distribución de etiquetas en sentido descendente a pedido con pedido

control (iniciado por el ingreso), etiqueta conservadora
modo de retención y detección de bucle opcional.
6. <PulledUnconditional, RequestWhenNeeded, N / A, ReleaseOnChange,

UseImmediate>
Esta es la distribución de etiquetas en sentido descendente a pedido con

control independiente y modo conservador de retención de etiquetas,
sin detección de bucle
7. <PulledUnconditional, RequestWhenNeeded, N / A, ReleaseOnChange,


control independiente y modo conservador de retención de etiquetas, con
detección de bucle
5.2.2 . Esquemas para LSR que no admiten la fusión de etiquetas
Supongamos que R1, R2, R3 y R4 son conmutadores ATM que no admiten

fusión de etiquetas, pero se están utilizando como LSR. Supongamos además que el
La ruta L3 hop-by-hop para el prefijo de dirección X es <R1, R2, R3, R4>, y eso
los paquetes destinados a X pueden ingresar a la red en cualquiera de estos LSR.
Como no hay capacidad multipunto a punto, los LSP deben estar
se realizan como VC punto a punto, lo que significa que debe haber
tres de tales VCs para el prefijo de dirección X: <R1, R2, R3, R4>, <R2, R3, R4>,
y <R3, R4>.
Por lo tanto, si R1 y R2 son pares MPLS, y cualquiera de ellos es un LSR que es

implementado utilizando hardware de conmutación ATM convencional (es decir, sin célula
supresión intercalada), o es incapaz de realizar
combinación de etiquetas, el esquema MPLS en uso entre R1 y R2 debe ser uno
de los siguientes:
1. <PulledConditional, RequestOnRequest, RequestRetry,

ReleaseOnChange, *>
Esta es la distribución de etiquetas en sentido descendente a pedido con pedido

control (iniciado por el ingreso), etiqueta conservadora
modo de retención y detección de bucle opcional.
El uso del procedimiento RequestOnRequest causará que R4

distribuir tres etiquetas para X a R3; R3 distribuirá 2
etiquetas para X a R2, y R2 distribuirá una etiqueta para X a
R1.
2. <PulledUnconditional, RequestOnRequest, N / A, ReleaseOnChange,

UseImmediate>

control independiente y modo conservador de retención de etiquetas,
sin detección de bucle
3. <PulledUnconditional, RequestOnRequest, N / A, ReleaseOnChange,


control independiente y modo conservador de retención de etiquetas, con
detección de bucle
5.2.3 . Consideraciones de interoperabilidad
Es fácil ver que ciertos quintuples NO producen MPLS viables

esquemas. Por ejemplo:
- <PulledUnconditional, RequestNever, *, *, *>

<PulledConditional, RequestNever, *, *, *>
En estos esquemas MPLS, el LSR Rd downstream distribuye la etiqueta

enlaces a LSR Ru aguas arriba solo a petición de Ru, pero Ru
nunca hace tales solicitudes. Obviamente, estos esquemas son
no viable, ya que no dará lugar a la adecuada
distribución de enlaces de etiquetas.
- <*, RequestNever, *, *, ReleaseOnChange>
En estos esquemas MPLS, Rd libera enlaces cuando no está usando

ellos, pero nunca los pide nuevamente, incluso si luego tiene una
necesidad de ellos. Por lo tanto, estos esquemas no aseguran que la etiqueta
enlaces se distribuyen correctamente.
En esta sección, especificamos reglas para evitar un par de etiquetas

compañeros de distribución de la adopción de procedimientos que conducen a inviable
Esquemas MPLS. Estas reglas requieren el intercambio de información
entre pares de distribución de etiquetas durante la inicialización de
adyacencia de distribución de etiquetas, o conocimiento a priori de
información (obtenida a través de un medio que está fuera del alcance de
documento).
1. Cada uno debe indicar si admite la fusión de etiquetas.
2. Si Rd no admite la fusión de etiquetas, Rd debe elegir entre

PulledUnconditional procedure o el PulledConditional
procedimiento. Si Rd elige PulledConditional, Ru se ve obligado a
use el procedimiento RequestRetry.
Es decir, si el LSR indirecto no es compatible con la fusión de etiquetas,

sus preferencias tienen prioridad cuando se elige el esquema MPLS.
3. Si Ru no admite fusión de etiquetas, pero Rd lo hace, Ru debe

elija el procedimiento RequestRetry o RequestNoRetry.
Esto obliga a Rd a usar el PulledConditional o
PulledUnConditional procedure respectivamente.
Es decir, si solo uno de los LSR no es compatible con la fusión de etiquetas,

sus preferencias tienen prioridad cuando se elige el esquema MPLS.
4. Si tanto Ru como Rd admiten la fusión de etiquetas, entonces la elección

entre el modo de retención de etiqueta liberal y conservador pertenece
a Ru. Es decir, Ru puede elegir usar
RequestWhenNeeded / ReleaseOnChange (conservador), o para usar
RequestNever / NoReleaseOnChange (liberal). Sin embargo, la elección
de "empujar" frente a "tirar" y "condicional" vs. "incondicional"
pertenece a Rd. Si Ru elige el modo liberal de retención de etiquetas, Rd
puede elegir PushUnconditional o PushConditional. Si Ru
elige el modo conservador de retención de etiquetas, Rd puede elegir
PushConditional, PulledConditional o PulledUnconditional.
Estas elecciones juntas determinan el esquema de MPLS en uso.
6 . Consideraciones de Seguridad
Algunos enrutadores pueden implementar procedimientos de seguridad que dependen del

el encabezado de la capa de red se encuentra en un lugar fijo en relación con el enlace
de datos
encabezado de capa La encapsulación genérica de MPLS inserta una cuña entre
el encabezado de la capa de enlace de datos y el encabezado de la capa de red. Esto
puede
causa que alguno de esos procedimientos de seguridad falle.
Una etiqueta MPLS tiene su significado en virtud de un acuerdo entre el

LSR que coloca la etiqueta en la pila de etiquetas (el "escritor de etiquetas"), y
el LSR que interpreta esa etiqueta (el "lector de etiquetas"). Si está etiquetado
los paquetes son aceptados de fuentes no confiables, o si un particular
la etiqueta entrante se acepta desde un LSR al que esa etiqueta no tiene
distribuido, entonces los paquetes pueden ser enrutados de forma ilegítima
manera.
7 . Propiedad intelectual
El IETF ha sido notificado de los derechos de propiedad intelectual reivindicados en

con respecto a algunas o todas las especificaciones contenidas en este
documento. Para obtener más información, consulte la lista en línea de reclamación
derechos.
8 . Direcciones de los autores
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
Correo electrónico: erosen@cisco.com
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd.
Milpitas, CA 95035-7438
Correo electrónico: arun@force10networks.com
Ross Callon
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 EE. UU.
Correo electrónico: rcallon@juniper.net
9 . Referencias
[ MPLS-ATM ] Davie, B., Lawrence, J., McCloghrie, K., Rekhter,

Y., Rosen, E., Swallow, G. y P. Doolan, "MPLS
usando LDP y ATM VC Switching ", RFC 3035 ,
Enero de 2001.
[ MPLS-BGP ] "Llevando la información de la etiqueta en BGP-4", Rekhter,

Rosen, trabajo en progreso.
[ MPLS-CR-LDP ] "Configuración de LSP basada en restricciones usando LDP", Jamoussi,

Editor, Trabajo en progreso.
[ MPLS-FRMRLY ] Conta, A., Doolan, P. y A. Malis, "Uso de la etiqueta

Activando la especificación de redes Frame Relay ",
RFC 3034 , enero de 2001.
[ MPLS-LDP ] Andersson, L., Doolan, P., Feldman, N., Fredette,

A. y B. Thomas, "Especificación LDP", RFC 3036 ,
Enero de 2001.

[ MPLS-RSVP-TUNNELS ] "Extensiones para RSVP para túneles LSP", Awduche,

Berger, Gan, Li, Golondrina, Srinvasan, Trabajar en
Progreso.
[ MPLS-SHIM ] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G.,

Farinacci, D. y A. Conta, "MPLS Label Stack"
Codificación ", RFC 3032 , enero de 2001.
[ MPLS-TRFENG ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M.

y J. McManus, "Requisitos para el tráfico"
Ingeniería sobre MPLS ", RFC 2702 , septiembre de 1999.

MPLS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MPLS

Caricato da

Copyright:

Formati disponibili

Arquitectura de conmutación de etiquetas multiprotocolo

Estado de esta nota

Este documento especifica un protocolo de seguimiento de estándares de Internet para

Este documento especifica la arquitectura para la etiqueta multiprotocolo

Rosen, et al. Normas Track [Page 1]

RFC 3031 MPLS Architecture Enero 2001

3.12 Mapa de FEC a NHLFE (FTN) ............................. 14

Rosen, et al. Normas Track [Page 2]

RFC 3031 MPLS Architecture Enero 2001

4.4 MPLS y enrutamiento de caminos múltiples ........................ 44

Este documento especifica la arquitectura para la etiqueta multiprotocolo

Tenga en cuenta que el uso de MPLS para multidifusión queda en estudio.

Rosen, et al. Normas Track [Page 3]

RFC 3031 MPLS Architecture Enero 2001

2.1 . Visión de conjunto

Como un paquete de un protocolo de capa de red sin conexión viaja desde

Los encabezados de paquetes contienen mucha más información de la necesaria

En el reenvío de IP convencional, un enrutador en particular típicamente

En MPLS, la asignación de un paquete particular a un FEC particular es

En saltos posteriores, no hay un análisis más detallado del paquete

En el paradigma de reenvío de MPLS, una vez que se asigna un paquete a un FEC,

RFC 3031 MPLS Architecture Enero 2001

- El reenvío MPLS puede realizarse mediante conmutadores que son capaces de

- Como un paquete está asignado a un FEC cuando ingresa a la red,

- Un paquete que ingresa a la red en un enrutador en particular puede ser

- Las consideraciones que determinan cómo se asigna un paquete a un

- A veces es deseable obligar a un paquete a seguir un

Algunos enrutadores analizan el encabezado de la capa de red de un paquete no solo para

Rosen, et al. Normas Track [Página 5]

RFC 3031 MPLS Architecture Enero 2001

MPLS significa cambio de etiqueta "multiprotocolo", multiprotocolo

Un enrutador que admite MPLS se conoce como "Enrutador de conmutación de etiquetas",

DLCI una etiqueta utilizada en redes Frame Relay para

expedir clase de equivalencia un grupo de paquetes IP que son

fusión de etiquetas de combinación de marcos, cuando se aplica a

etiquetar una corta longitud fija físicamente

etiqueta fusionando el reemplazo de múltiples entrantes

etiqueta intercambiar la operación de reenvío básico

etiqueta de intercambio de un paradigma de reenvío que permite

Rosen, et al. Normas Track [Page 6]

RFC 3031 MPLS Architecture Enero 2001

etiqueta conmutada hop el salto entre dos nodos MPLS, en el cual

ruta conmutada de etiqueta La ruta a través de uno o más LSR a la vez

enrutador de conmutación de etiquetas un nodo MPLS que es capaz de

capa 2, la capa de protocolo debajo de la capa 3 (que

capa 3 la capa de protocolo en la que IP y su

detección de bucle un método de tratar con bucles en el que

prevención de bucles un método de tratar con bucles en el que

etiqueta apila un conjunto ordenado de etiquetas

punto de fusión un nodo en el que se realiza la fusión de etiquetas

Dominio MPLS un conjunto contiguo de nodos que operan

Nodo MPLS Edge un nodo MPLS que conecta un MPLS

Rosen, et al. Normas Track [Page 7]

RFC 3031 MPLS Architecture Enero 2001

Nodo de salida MPLS un nodo de borde MPLS en su rol en

Nodo de entrada MPLS un nodo de borde MPLS en su rol en

MPLS etiqueta una etiqueta que se lleva en un paquete

Nodo MPLS un nodo que ejecuta MPLS. Un MPLS

Etiqueta MultiProtocol Conmutación de un grupo de trabajo IETF y

capa de red sinónimo de capa 3

pila con pila de etiquetas

ruta conmutada sinónimo de ruta conmutada de etiqueta

circuito virtual un circuito utilizado por una conexión orientada

Combinación de combinación de etiquetas de VC donde se encuentra la etiqueta MPLS