Este documento explica por qué el router periférico del proveedor IPv6 (6PE) de Cisco IOS© utiliza dos etiquetas de conmutación de etiquetas multiprotocolo (MPLS) en el plano de datos.
A. 6PE utiliza dos etiquetas:
La etiqueta superior es la etiqueta de transporte, que el protocolo de distribución de etiquetas (LDP) o la ingeniería de tráfico MPLS (TE) asignan salto por salto.
La etiqueta inferior es la asignada por el protocolo de gateway fronterizo (BGP) y anunciada por el BGP interno (iBGP) entre los routers de borde del proveedor (PE).
Cuando se lanzó el 6PE, un requisito principal era que ninguno de los routers de núcleo MPLS (los routers IP) tuviera que ser compatible con IPv6. Ese requisito obligó a que se necesitaran dos etiquetas en el plano de los datos. Hay dos razones por las que el 6PE necesita ambas etiquetas.
Funcionalidad PHP
Si solo se utilizara la etiqueta de transporte y se utilizara el penúltimo salto emergente (PHP), el penúltimo router de salto (el router P) tendría que entender IPv6.
Con PHP, este penúltimo router de salto tendría que quitar la etiqueta MPLS y reenviar el paquete como un paquete IPv6. Este router P tendría que saber que el paquete es IPv6 porque el router P tendría que utilizar el tipo de encapsulación de capa 2 correcto para IPv6. (El tipo de encapsulación es diferente para IPv6 e IPv4; por ejemplo, para Ethernet, el tipo de encapsulación es 0x86DD para IPv6, mientras que es 0x0800 para IPv4.) Si el penúltimo router de salto no es compatible con IPv6, probablemente colocaría el tipo de encapsulación de Capa 2 para IPv4 para el paquete IPv6. El router PE de salida creería entonces que el paquete era IPv4.
Existe un procesamiento de tiempo de vida (TTL) en los encabezados IPv4 e IPv6. En IPv6, el campo se denomina Límite de salto. Los campos IPv4 e IPv6 se encuentran en diferentes ubicaciones en los encabezados. Además, también debería modificarse Header Checksum en el encabezado IPv4; no hay ningún campo Header Checksum en IPv6. Si el penúltimo router de salto no es compatible con IPv6, provocaría que el paquete IPv6 esté mal formado, ya que el router espera encontrar el campo TTL y el campo Header Checksum en el encabezado.
Debido a estas diferencias, el penúltimo router de salto debería saber que es un paquete IPv6. ¿Cómo sabría este router que el paquete es un paquete IPv6, ya que no asignó una etiqueta a la clase de equivalencia de reenvío (FEC) IPv6 y no hay campo de encapsulación en el encabezado MPLS? Podría buscar el primer bocado después de la pila de etiquetas y determinar que el paquete es IPv6 si el valor es 6. Sin embargo, esto implica que el penúltimo router de salto debe ser compatible con IPv6.
Este escenario podría funcionar si se utiliza la etiqueta null explícita (por lo tanto, no hay PHP). Sin embargo, la decisión fue requerir PHP.
Equilibrio de carga
El balanceo de carga típico en un router P sigue este proceso. El router IP va al final de la pila de etiquetas y determina si se trata de un paquete IPv4 observando el primer fragmento después de la pila de etiquetas.
Si el nibble tiene un valor de 4, la carga útil MPLS es un paquete IPv4 y la carga del router IP se equilibra troceando las direcciones IPv4 de origen y destino.
Si el router P es compatible con IPv6 y el valor de nibble es 6, la carga del router P se equilibra troceando las direcciones IPv6 de origen y destino.
Si el router P no es compatible con IPv6 y el valor del nibble no es 4 (podría ser 6 si el paquete es un paquete IPv6), el router P determina que no es un paquete IPv4 y toma la decisión de equilibrio de carga basándose en la etiqueta inferior.
En el escenario 6PE, imagine que hay dos routers PE de salida que anuncian un prefijo IPv6 en BGP hacia el router PE de entrada. Este prefijo IPv6 se anunciaría con dos etiquetas diferentes en BGP. Por lo tanto, en el plano de datos, la etiqueta inferior sería cualquiera de las dos etiquetas. Esto permitiría a un router P equilibrar la carga en la etiqueta inferior por flujo.
Si 6PE utiliza solamente la etiqueta de transporte para transportar los paquetes 6PE a través del núcleo MPLS, los routers P no podrían balancear la carga de estos paquetes por flujo a menos que los routers P fueran compatibles con IPv6. Si los routers IP fueran compatibles con IPv6, podrían utilizar las direcciones IPv6 de origen y destino para tomar una decisión de equilibrio de carga.