Join the hybrid engineer movement. Free webinars to get you started.

El volumen de datos multicast no sólo ha ido creciendo en los últimos años sino que continuará haciéndolo en el futuro. Para cubrir esta demanda, SPs e ISPs necesitan una solución escalable que les permita aumentar el volumen de datos transportado (IPTV) y dar servicio a una nueva generación de aplicaciones que demanda cada vez más la distribución de contenido multicast en tiempo real (telepresencia, juegos).

 

Por otro lado, la demanda de servicios multicast por parte de los clientes también está creciendo debido sobre todo a las nuevas aplicaciones que satisfacen las necesidades empresariales actuales de una forma más eficiente usando la tecnología multicast.

 

La solución MPLS L3 VPN para el tráfico unicast se recoge en las RFCs 2547 y 4364. El protocolo Next-Generation Multicast VPN (NG mVPN) tiene como objetivo ofrecer un servicio integrado MPLS L3 VPN que cubra tanto el servicio de tráfico multicast como multicast recogiendo las siguientes características:

 

  • Única tecnología de encapsulación

  • Planos de Datos y de Control compartidos.

  • Advanced Traffic Engineering (TE) capabilities.

  • Fast Restoration (FR) and protection mechanisms.

  • Sin necesidad de incluir protocolos adicionales en el Core (no PIM)

  • Aisle los dispositivos del Core de los datos de estado multicast del cliente.

 

En esta entrada se describirán los conceptos básicos de los Árboles de Distribución Multicast (MTD) en el Core y los protocolos involucrados en su construcción, así como las diferencias más relevantes entre los modelos Classic y NG mVPN que deben ser consideradas en el diseño de una solución multicast.


Árboles de Distribución Multicast

 

En esta sección se analizarán los Árboles de Distribución Multicast (MDT) como árboles de distribución que interconectan los dispositivos PE del proveedor de servicios en el core de la red.


Estos MDTs transportan los datos de los clientes encapsulados a través del Core entre aquellos PEs de entrada y salida que comparten al menos un mVPN. Los MDTs pueden clasificarse como inclusivos o selectivos:


  • Inclusive Trees: 1 MDT por mVPN. Todo el tráfico de una determinada Fuente se asigna al mismo árbol y será entregado desde el PE de entrada a todos los PEs de salida.

  • Selective Trees: 1 MDT por mVPN por Fuente. Se define un MDT por cada Fuente presente en un mVPN.

 

La eficiencia de los Árboles Selectivos (Selective Trees) es mayor que en el caso de los Árboles Inclusivos (Inclusive Trees) porque estos últimos entregan el tráfico a todos los PEs, incluidos aquellos que no tienen receptores interesados. En el caso en el que sea posible realizar agregación en el underlay, pueden usarse los Árboles inclusivos agregados y los Árboles Selectivos Agregados:


  • Aggregate inclusive tree: Se comparte 1 MDT entre todos los grupos de más de un mVPN. 1 MDT is shared by all groups from more than one mVPN.

  • Aggregate selective tree: 1 MDT puede ser compartido por grupos multicast de diferentes mVPNs.

 

 



La relación entre las tres clases de MDT más comunes en el Core y el tipo de árbol multicast asociado se reflejan en la figura anterior:


  • Default MDT (Multidirectional Inclusive): empleado por el mVPN para el transporte de datos relacionados con la señalización de protocolos y los flujos de datos que requieren poco ancho de banda y están destinados a un conjunto amplio y disperso de receptores.

  • Data MDT (Selective): empleados para evitar el envío innecesario de tráfico, en el Data MDT se envía el tráfico multicast de una Fuente a un conjunto conocido de Receptores interesados.

  • Partitioned MDT (Multidirectional Selective): Se trata de un Default MDT creado entre un conjunto de PEs que forman parte del mismo mVPN.

 

 

.Default MDTData MDTPartitioned MDT
Conectividad entre PETodosSubconjuntoSubconjunto de PEs
RoutingBidireccionalUnidireccionalAmbos
DisponibilidadSiempre ONBajo demandaBajo demanda
UsoControl and DatosDatosDatos
Nombre de la RFCMI-PMSIS-PMSIMS-PMSI
Protocolos de señalizaciónPIM, Full-mesh P2MP mLDP, MP2MP mLDP, Full-mesh P2MP TEPIM, P2MP mLDP, P2MP TEPIM, Partial-mesh P2MP mLDP, MP2MP mLDP, Partial-mesh P2MP TE

 

Protocolos de Señalización de Árboles Multicast en el Core


Existe una amplia variedad de protocolos que pueden ser empleados en la señalización de los MDTs. La selección de uno u otro dependerá de los requisitos de negocio de la solución multicast y de las condiciones impuestas en el diseño como pueden ser los recursos disponibles.


Los principales protocolos que se emplean en la señalización y construcción de los Árboles Multicast en el Core (underlay) son: PIM, mLDP, P2MP TE e IR.


PIM se puede usar cuando el MDT no requiere cambios. Es el mismo protocolo de señalización empleado en la construcción de los Source Tree, Shared Tree y Bidirectional Tree. La versión PIM dependerá de la relación optimización vs estado que requiera la solución multicast. En general, se puede decir que existen dos versiones de PIM para la señalización de los Shared Trees. PIM-SSM construye árboles multicast óptimos a costa de más estado y PIM-BiDir crea árboles con poca carga de estado a costa de utilizar caminos subóptimos. Cuando se emplea PIM, la copia y reenvío de datos multicast se realiza en los routers del Core.


mLDP es una extensión del protocolo LDP que se puede usar en la construcción de árboles multicast cuando existe protección de enlace en el Core (via MPLS-TE o FRR). Al igual que en el caso de PIM, la copia y reenvío de datos se realiza en el Core de la red. mLDP soporta la creación de dos tipos de árboles: P2MP y MP2MP (Bidirectional Tree).


P2MP TE utiliza extensiones de RSVP TE y de IGP para la construcción de árboles P2MP en el plano de datos. Al igual que los protocolos anteriores, la copia y reenvío de datos se realiza en los routers del Core. Su principal ventaja es que puede usarse como solución en diseños con requisitos de reserva de ancho de bando o uso específico de rutas. Al igual que mLDP, P2MP TE tiene capacidad de protección de enlace.


Ingress Replication (IR) es una opción que se basa en la reutilización de los LSPs existentes en el Core de la red. Se trata de una solución adecuada cuando existen limitaciones de compatibilidad o disponibilidad para implementar otras opciones como P2MP TE o mLDP. Esta opción puede considerarse como solución en entornos simples, con baja carga de tráfico o para escenarios inter-AS sencillos. Con IR el copiado y reenvío de datos se realiza en el PE de entrada y este factor es una limitación de escalabilidad importante.

 

 

Protocolo de señalizaciónPIMmLDPP2MP TEIR
EstadoBajoAltoBajoAlta
EncapsulaciónGRE (Rosen)MPLSMPLSMPLS
Copia y reenvío de datosCoreCoreCoreEntrada
Estado en Core MedioMedioAltoBajo
ComplejidadAltaMedia AltaBaja
Protection / Fast RestorationNoYesYesHeredado
Reserva ancho de bandaNoNoYesHeredado
Rutas explícitasNoNoYesHeredado
Más adecuado paraTodos los modelosMuchos-a-muchosPocos-a-muchosUno-a-muchos
Tunneling modelP2MPP2MP, MP2MPP2MPP2P

 

Arquitectura

 

Existen dos modelos básicos para el despliegue de mVPN:  Classic mVPN and NG mVPN.


Classic mVPN (PIM/GRE) está basado en Draft Rosen y requiere PIM en el Core del proveedor para poder soportar tráfico mVPN. Este requisito añade nuevos protocolos (PIM) y mecanismos de encapsulación (mGRE) en los planos de datos y de control. Como se verá, se trata de un modelo poco flexible y poco escalable.


NG mVPN (BGP/MPLS) parte de los mismos protocolos empleados en el servicio unicast MPLS L3 VPN (RFC 2547, RFC 4364 BGP MPLS VPNs) y les añade algunas extensiones necesarias para poder soportar el tráfico multicast. Este modelo conserva la buena escalabilidad y flexibilidad del servicio unicast VPN.


 

Modelo mVPN Classic mVPNNG mVPN
ServiceMPLS L3 VPN MulticastMPLS L3 VPN Unicast y Multicast
Overlay, Signaling, Control PlanePIMBGP
Underlay, Transport, Data Plane, Multicast Distribution Trees (MDT)PIM/GRE - mGRE tunnelingMDTs per VRF in Global RTmLDP, P2MP TE, IR
Bandwidth Res., TE and FRR
Core tree typesDefault MDT, Data MDTDefault MDT, Data MDT, Partitioned MDT

 

Classic mVPN (PIM/GRE)

 

El modelo Classic mVPN es la primera solución para el transporte de datos multicast entre sites de un mismo cliente sobre un Core de SP con capacidad multicast. Está basado en el modelo Virtual Router (VR), dónde cada VR del dominio VPN ejecuta una instancia de un protocolo de enrutamiento para el intercambio de información entre ellos.



 

 

Classic mVPN utiliza una instancia diferente del protocolo de enrutamiento (PIM) por mVPN entre PEs. En la práctica esto se traduce en que existe un plano de control diferente por mVPN, y, como consecuencia, un número elevado de enlaces y adyacencias en cada dispositivo PE.


PIM es un protocolo con una baja carga de estado y, por diseño, está basado en el uso de temporizadores. Este hecho supone que, a medida que el número de mVPN crece, el tráfico del plano de control necesario para mantener las adyacencias PIM también aumenta, limitando la escalabilidad de la solución.


En el underlay, este modelo también usa PIM. El uso de PIM en el underlay se hace necesario para configurar los túneles mVPN (mGRE) entre los dispositivos PE (MDTs). Son túneles lógicos que interconectan instancias mVRF y pueden usarse como enlaces normales. El protocolo de enrutamiento del cliente será tunelizado sobre ellos, con el consiguiente acoplamiento entre los planos de datos y de control.

 

NG mVPN (BGP/MPLS)

 

El modelo NG mVPN define una extensión del modelo unicast MPLS L3 VPN para el tráfico multicast. Este modelo está basado en el modelo Aggregated Routing (AR) VPN, dónde existe un protocolo de enrutamiento en el backbone que es el responsable de difundir la información de enrutamiento para todos los VPNs a todos los miembros del VPN.

 

 

 

Con el modelo NG mVPN una única instancia del protocolo de enrutamiento (BGP) es capaz de transportar toda la información de enrutamiento de mVPN para todos los mVPN, lo que tiene como resultado una agregación de la información de enrutado en un único plano de control común. En este caso, el protocolo de enrutamiento sólo necesita una adyacencia por cada par de dispositivos PE y por Route Reflector (RR).


BGP es un protocolo con una carga elevada de estado, lo que significa que utiliza actualizaciones cuando se produce un cambio en la información de enrutado y no está basado en temporizadores ni en el envío periódico de información actualizada, ayudando a mantener un plano de control más estable.


La configuración del plano de datos soporta diferentes tecnologías de tunneling y no se limita a PIM.  mLDP, P2MP TE e IR pueden usarse como mecanismos de encapsulación manteniendo el mismo plano de control (BGP) y soportando agregación en el plano de datos.


En este caso el intercambio de la información de enrutamiento está separado ya que tanto el transporte de los datos de mVPN como los datos del plano de control no usan el plano de datos de los túneles para el envío de la información de enrutamiento. No existe dependencia entre los planos como en el modelo anterior.


La introducción de BGP como protocolo del plano de datos añade algunas ventajas vistas en la solución unicast de MPLS L3 VPN como son la escalabilidad, la jerarquía y la agregación. Además deben tenerse en cuenta otras capacidades específicas de multicast, como pueden ser el end-point Auto Discovery (AD) y el Automatic Tunnel Binding (ATB) que fueron incorporados en la BGP multicast AF (mVPNv4 and mVPNv6).

 

Inter-AS peering

 

La integración inter-AS no es sencilla para las opciones B y C cuando se usa Classic mVPN. En el plano de control, este modelo necesita el intercambio directo de tráfico del plano de control (PIM) entre PEs. En los modelos de PIM/GRE la interconexión de los dispositivos PEs necesitan verse como si estuviesen conectados de forma directa (Emulated LAN).


En el plano de datos, todos los SPs deben soportar los túneles mGRE en el Core y en y en sus enlaces con los PEs  de forma directa. Los dispositivos PE necesitan verse como si estuvieran directamente conectados incluso si pertenecen a diferentes AS y aunque ésta sea una situación raramente deseable.


La integración inter-AS cuando se usa el modelo NG mVPN es mucho más flexible, soportando diferentes tecnologías de tunneling entre diferentes AS así como la construcción de árboles segmentados en escenarios inter-AS. El enrutamiento basado en BGP/MPLS hace posible que la distancia inter-PE pueda ser considerada en el proceso de selección de la ruta mVPN (no siendo posible en el caso de Emulated LAN). En este caso, los dispositivos PE no necesitan verse como si estuvieran directamente conectados entre ellos como sucede en la solución PIM/GRE.


Resumen

 

En la siguiente tabla se recogen los puntos de diseño más relevantes de mVPN comparando los dos modelos Classical y NG mVPN.



ScopeDesign TopicClassic mVPNNG mVPN
Plano de ControlModelo VPNVirtual Router (VR)Aggregated Routing (AR)
Protocolo plano datosPIM (overlay)MP-BGP
Routing protocol instances1 per mVPN1 BGP instance
Adyacencias1 por PE por instancia mVPN 1 por RR por PE
Agregación de información de rutasNo
Acoplamiento entre los planos de control y datos Altamente acopladosNo dependencia entre planos
ActualizaciónLow State (basado en temporizadores)Hard State (Basado en actualizaciones de BGP)
Conectividad Inter-AS Enlace directoEnlace indirecto
Eficiencia del enrutamientoSubóptimo (emulated LAN)Optimizable (uso distancias en BGP)
Plano de datosProtocolos de Tunneling PIM (underlay)mLDP, P2MP TE, IR
Flexibilidad del protocolo de Tunneling No
EncapsulationmGREMPLS LSPs
Configuración del MDT ManualBGP tunnel auto discovery and binding
Agregación de MDTNo, 1 MDT por mVPN (como mínimo)Soporta agregación
GeneralEficienciaBajaAlta
Plano de control jerárquicoNo
StateHigh (due to lack of aggregation)Low
ScalabilityLow (due to PIM)High (due to BGP)
DeploymentHard (new protocols)Easy (extensions to existing protocols)
OPEXHighMedium

 

 

mVPN.- Referencias Adicionales

 

En las siguientes referencias se puede obtener información adicional sobre los modelos Classic mVPN y NG mVPN.