PROFORMA Serial no :
ABBREVIATIONS
La tabla de ruteo IP Multicast es generada y actualizada por los protocolos de ruteo IP Multicast. El módulo MPLS en los LSR mapeará la topología generada por esta, en capa 3, en
LSPs punto a multipunto en capa 2.
La desventaja de este mecanismo es que se consumen etiquetas MPLS aun cuando no se tenga transmisión de flujos de datos IP Multicast.
4.3.3. TRAFFIC DRIVEN.
Sólo se construyen LSPs para árboles de distribución IP Multicast que transporten tráfico, lo cual reduce la utilización de etiquetas MPLS.
Si los LSRs no soportan realizar un forwarding combinado entre capa 2 y capa 3, este mecanismo para la generación de LSPs requerirá de un método de distribución de etiquetas en el cual la información de etiquetas es solicitada por el LSR de Upstream.
MPLS Multicast es independiente de los protocolos de ruteo IP Multicast en si.
4.4. PIGGY-BACKING.
Brinda un mecanismo alternativo a enviar dos mensajes separados. Así, la información de etiqueta puede ser obtenida realizando un piggy-backing sobre los mensajes de control. Podemos tener dos alternativas:
a. Mensajes de Ruteo IP Multicast: los protocolos PIM-SM y CBT poseen mensajes explícitos de Join, los cuales permiten transportar la información de etiqueta mapeada sobre los mismos mensajes. Para otros tipos de protocolos de ruteo IP Multicast será necesario realizar una extensión de los mismos.
b. Mensajes RSVP Resv: se utiliza una extensión de objeto de modo de permitir el mapeo de la información de etiqueta sobre este tipo de mensajes.
Este método presenta las siguientes ventajas y desventajas:
Ventajas.
a. Se tiene una sincronización entre la distribución de etiquetas y la distribución de rutas IP Multicast. Lo cual permite minimizar el intervalo entre el establecimiento de la ruta IP Multicast y el mapeo de la etiqueta MPLS para una dada ruta.
b. La cantidad de mensajes de control necesarios para realizar la publicación de etiquetas, más allá de las necesarias para soportar protocolos de ruteo IP Multicast, es cero.
Desventajas.
a. Para protocolos de ruteo IP Multicast de características Dense Mode, como PIM-DM, no se tiene la posibilidad de realizar piggy-backing sobre mensajes de control.
b. No es posible tener co-existencia de árboles de distribución IP Multicast Source y
Shared Tree.
c. Requiere la extensión de algunos protocolos de ruteo IP Multicast para soportar la funcionalidad de piggy-backing, lo cual sucede en caso de tener que soportar múltiples protocolos de ruteo IP Multicast.
d. Implica la utilización del modo de distribución de etiquetas Downstream Unsolicited, lo cual excluye la posibilidad de utilizar alguno de los métodos de Trigger según se vio en puntos anteriores.
e. LDP utiliza TCP para asegurar una comunicación confiable entre LSRs. La utilización de piggy-backing a menudo reemplaza esta comunicación confiable con mensajes periódicos soft-states. Esto incrementa la cantidad de mensajes de control de tráfico.
f. Si se requiere la utilización de un mecanismo VCID la notificación, inband, puede ser realizada enviando el binding de LDP a través del nuevo VC, requiriéndose sólo un mensaje. Este método no se puede combinar con la funcionalidad de piggy-backing, ya que la información de ruteo es enviada antes que el VC sea establecido.
4.5. EXPLICIT ROUTING.
Explicit Routing, para el caso de tráfico IP Unicast, implica el poder “sobreescribir” la tabla de ruteo IP Unicast utilizando LSPs.
Para el caso de tráfico IP Multicast, implicaría la posibilidad de “sobreescribir” el árbol de distribución establecido por el protocolo de ruteo Multicast utilizando la información de otro LSP. Así, el protocolo de ruteo shortest path se vuelve obsoleto y puede ser reemplazado por los mensajes de publicación de información de etiqueta que siguen una ruta explícita.
4.6. DIFFSERV.
Esta funcionalidad permite tener una mayor granularidad en los flujos de datos IP Multicast, requiriendo la utilización de un nuevo código DSCP, DiffServ Codepoint, para la designación de los árboles de distribución IP Multicast. Así, una fuente de tráfico IP Multicast puede establecer uno o más árboles de distribución con diferentes DSCPs.
De esta manera, la asignación de los árboles de distribución IP Multicast serán (S,G,DSCP) o (*,G, DSCP). Estos pueden ser “mapeados” fácilmente sobre LSPs MPLS utilizando el método de Traffic Driven Trigger. Así, se pueden generar LSPs con diferentes atributos. Estos LSPs utilizarán la misma ruta IP Multicast, ya que la construcción de los mismos no toma en cuenta la información de DCSP.
4.7. REDES MULTIACCESO.
En el caso de IP MPLS Multicast sobre redes multiacceso, como Ethernet, los LSRs que requieran unirse a un grupo IP Multicast deben estar siempre “listos” para aceptar la etiqueta que fue asignada a un dado grupo LSP Multicast. Esto puede lograrse de las siguientes formas:
a. Cada LSR conectado a la red Multiacceso almacena todas las etiquetas publicadas sobre el enlace multiacceso, aun cuando no haya recibido un mensaje de Join para un determinado grupo IP Multicast. Si un nuevo LSR es conectado a la red multiacceso, debe recibir la información de las etiquetas asignadas de algún otro
LSR conectado al enlace, y en caso de utilizar publicación de etiquetas mediante el método Soft State, puede esperar un cierto tiempo hasta que sea capaz de almacenar etiquetas por él mismo.
b. Cada LSR obtiene su propio rango del cual realizar el almacenamiento y asignación de etiquetas. Así, si un nuevo LSR se agrega sobre el enlace multiacceso, el rango de etiquetas deberá ser negociado con el resto de los LSR conectados.
c. Para cada enlace multiacceso, un LSR puede ser elegido para ser responsable del almacenamiento y asignación de etiquetas. Así, cuando un LSR necesita realizar la asignación de una etiqueta, obtiene esta consultando al LSR designado para tal fin.
En el caso que un flujo de datos IP Multicast tenga más de un LSR Downstream, los cuales requieran utilizar la misma etiqueta MPLS, podemos tener dos soluciones:
a. Realizar la publicación de la información de etiqueta en modo Multicast hacia todos los LSRs conectados sobre el enlace compartido.
b. Un LSR enviará la información de etiqueta en modalidad Unicast, utilizando un protocolo confiable, TCP, hacia uno o todos los LSRs sobre el enlace compartido que requieran esta información.
Debido a que el establecimiento de LSPs considera si se tiene un tiempo de vida,
lifetime, suficiente, y teniendo en cuenta que el número de LSRs sobre un enlace multiacceso es limitado, la opción b presenta condiciones más ventajosas.
Otro punto a tener en cuenta para el caso de enlaces multiaccesos es la decisión entre utilizar asignación de etiquetas Upstream o Downstream. Para tráfico IP Multicast, la asignación de etiquetas en sentido Upstream es más simple, ya que puede haber un sólo nodo Upstream que por enlace pertenezca a un árbol de distribución IP Multicast. Este nodo asignará una única etiqueta para un dado FEC. Con la asignación en modo Downstream puede haber múltiples nodos para un árbol determinado en un enlace multiacceso, cada nodo puede proponer una etiqueta diferente para un dado FEC, lo cual requerirá de la utilización de algún proceso determinado para garantizar una única etiqueta MPLS para un dado FEC sobre un enlace multiacceso.
Una vez que una etiqueta fue asignada es posible que el nodo, o LSR, que realizó la asignación de la misma “abandone” el enlace multiacceso. Para el caso de asignación
Downstream, esto puede suceder cuando el LSR que asignó la etiqueta deje de pertenecer al grupo Multicast. En el caso de asignación de etiquetas utilizando la metodología Upstream, puede suceder cuando el LSRUpstream cambie debido a un cambio en la topología.