Descripcin del Grupo de Trabajo El grupo de trabajo de MPLS es responsable para la normalizacin de una base tecnologa para el uso

de conmutacin de etiqueta y para la aplicacin de etiqueta de conmutacin de paquetes de diversos caminos en base a nivel de enlace tecnologas, tales como paquetes-sobre-SONET, Frame Relay, ATM, y LAN tecnologas (por ejemplo, todas las formas de Ethernet, Token Ring, etc.) Esto incluye los procedimientos y protocolos para la distribucin de etiquetas entre los routers y la encapsulacin. El grupo de trabajo tambin es responsable de especificar las medidas necesarias objetos de administracin (por ejemplo, como parte de los mdulos MIB) y las tcnicas de OAM la funcionalidad especificada en la base de la tecnologa MPLS. La primera generacin de los estndares MPLS son en gran medida completa, y los actuales elementos del Grupo de Trabajo de trabajo son: - Definir los requisitos, los mecanismos y las extensiones de protocolo para punto a multipunto (P2MP) MPLS - Definir los requisitos, los mecanismos y las extensiones de protocolo para ingeniera de trfico de punto a multipunto (P2MP) de MPLS, incluyendo sobreseimiento suave - Definir los requisitos y mecanismos para MPLS OAM - Definir un marco general para las aplicaciones de OAM MPLS - MPLS aspectos especficos de la ingeniera de trfico para multi-areas/multi-AS en colaboracin con el Grupo de Trabajo CCAMP - Determinar (con CCAMP) qu procedimientos son adecuados para evaluar propuestas para ampliar el MPLS y GMPLS protocolos, y documentar estas - Documento de las prcticas de ejecucin actual de reparto de carga MPLS - Incluir a las extensiones de los protocolos MPLS WG y RFC necesario crear un perfil de transporte MPLS (MPLS TP). El trabajo en el TP MPLS forma coordinada entre los grupos de trabajo (por ejemplo, PWE3 MPLS, CCAMP, y L2PVN) que se alquilan para hacer el trabajo MPLS TP.

Una especificacin de MPLS siembra la discordia entre el IETF y la UIT

Los organismos de estandarizacin IETF (Internet Engineering Task Force) y la UIT (Unin Internacional de Telecomunicaciones) se han convertido en rivales por un conjunto de especificaciones MPLS que, segn el IETF, podran generar problemas de interoperabilidad para los proveedores de servicios si no se cambian. El IETF ha abierto una brecha frente a la UIT por una arquitectura de red de transporte especial que est desarrollando el sector de estandarizacin de telecomunicaciones de este ltimo (ITU-T, por sus siglas en ingls), cuyo objetivo es permitir que el trfico MPLS pueda discurrir sobre una troncal Ethernet. En este comit estn involucrados proveedores de equipamiento de red como Alcatel-Lucent, Ericsson, Fujitsu y Tellabs. Concretamente, T-MPLS est siendo desarrollado por el Study Group 15 Working Party 3 de la ITU-T, que trata la estructura de red de transporte ptico. Este grupo viene trabajando en T-MPLS desde hace tres aos y ha finalizado cuatro especificaciones, incluyendo un documento sobre arquitectura, un interfaz red a red, una especificacin de equipamiento y un documento sobre conmutacin. La razn de estos trabajos es, de acuerdo con la ITU-T, que los proveedores de servicios necesitan un perfil especial o una subred de MPLS para satisfacer sus requisitos. De esta manera, por ejemplo, T-MPLS soportar mensajera y entornos operativos (OE&M) y conmutacin de proteccin ms robustos que los proporcionados por el estndar MPLS del IETF. El problema, segn el IETF, es que la especificacin T-MPLS (Transport-MPLS) de la UIT no funcionar con los routers y conmutadores basados en estndares MPLS del IETF desplegados, tras una elevada inversin, por los operadores en los ltimos aos. La situacin puede ser catastrfica, afirma Stewart Bryant, enlace del IETF con la ITU-T en materias de MPLS y responsable tcnico de Cisco. El principal problema es que T-MPLS utiliza el mismo EtherType campo del estndar de red Ethernet que indica qu protocolo est siendo transportado y cmo procesar los paquetes- que MPLS, lo que podra generar confusin en la operacin de las redes. La propuesta del IETF es que T-MPLS debera usar un EtherType diferente, idealmente llamado T-MPLS, para que no haya confusin al gestionar el trfico T-MPLS y MPLS, explica Bryant. No debera haber nada diseado, implementado o especificado que arriesgue la base desplegada de equipos MPLS. Para Stephen Trowbridge, presidente del Working Part 3 del Study Group 15 y empleado de Alcatel-Lucent, la crisis de T-MPLS es una guerra de poder entre el IETF y la ITU-T en la que estn influyendo las propias emociones de los integrantes de ambos organismos de estandarizacin. No obstante, admite un cierto contencioso. Todo converge. Cada vez ms vemos tecnologa ptica aplicndose en el extremo de la red. Y ms tecnologas de

paquetes en las redes de los proveedores de servicios. Las guerras de poder son inevitables.

Cruce de acusaciones El ncleo de la polmica reside en que la ITU-T est utilizando diversas tecnologas desarrolladas por el IETF en T-MPLS, incluyendo MPLS EtherTypes Pseudowire Emulation Edge to Edge (PWE3) para sus puntos de cdigo. Asimismo, T-MPLS duplica los planos de control, gestin y reenvo utilizado por los estndares MPLS del IETF. Este organismo argumenta que T-MPLS emplea dichas tecnologas de un modo incompatible y diferente a como estn definidas en sus estndares MPLS y que, por tanto, los trficos TMPLS y MPLS no pueden coexistir en una red. Por su parte, los integrantes del ITU-T niegan que T-MPLS vaya a crear problemas de interoperabilidad con Internet, ya que el estndar se utilizar nicamente en la red del proveedor de servicios y no traspasar a la red del cliente. Para transportar trfico MPLS de una red empresarial sobre una red T-MPLS de un proveedor de servicios, el MPLS empresarial ir sobre Ethernet. Ser T-MPLS en la red del proveedor de servicios y cuando se entregue al cliente, la etiqueta de T-MPLS se eliminar y el cliente recuperar su trfico sobre Ethernet, explica el portavoz de la ITU-T. Cuando se examina ese modelo de servicio, es difcil ver cmo podra haber un conflicto de protocolos. Sin embargo, los directivos del IETF consideran esta visin como poco realista. Tenemos la experiencia de que incluso cuando se ha diseado y planificado cuidadosamente, en la prctica raramente los elementos de red permanecen independientes, explica el IETF en una carta enviada a Malcolm Johnson, director del Bur de Estandarizacin de Telecomunicaciones de la ITU, a finales de julio, apremiando al organismo a cambiar el curso de T-MPLS. La configuracin accidental sucede y puede ser un factor significativo para provocar serias cadas de la red u otros incidentes. El uso de EtherTypes comunes para el IETF MPLS y T-MPLS, del modo en el que lo est definiendo el ITU-T Study Group 15, representa un peligro mutuo tanto para Internet como para las redes de transporte que llevarn T-MPLS. Esto no debera avanzar, reza la carta del IETF. La entidad propone que ambos organismos colaboren para integrar los requisitos de T-MPLS en el proceso de estandarizacin del IETF para garantizar que trabajarn con los estndares MPLS actuales. Creemos que as se podra satisfacer el objetivo mutuo de mejorar la funcionalidad de Internet y las redes de transporte y de garantizar la completa interoperabilidad y la solidez de la arquitectura. Asimismo, el IETF recomienda que la UIT cambie T-MPLS de forma que utilice diferentes puntos de cdigo para sus planos de

control, gestin y planificacin.

Un paso hacia la resolucin No es la primera vez que el IETF se queja de que T-MPLS utiliza el mismo EtherType que MPLS. Hace un ao, el foro envi una carta a la ITU-T pidindole que T-MPLS utilizara diferentes EtherTypes. Tras la misiva, ambas entidades se reunieron y llegaron al consenso de utilizar EtherTypes comunes para MPLS y T-MPLS. Sin embargo, cuando todo se crea solucionado, lleg la reciente carta del IETF. El enlace entre ambos organismos, Sthewart Bryant, afirma que T-MPLS ha causado ms disputas entre el IETF y la UIT de lo que normalmente sucede en el desarrollo de estndares de Internet. Es inusual. Ha habido demasiadas discusiones. Esperamos que podamos trabajar juntos y resolver los problemas de forma amigable. Queremos producir tecnologa que satisfaga a todos pero hacerlo de un modo que no introduzca confusin en la red. A partir de hoy, el grupo de trabajo de T-MPLS mantendr una reunin en Stuttgard (Alemania), y a ella acudirn varios integrantes del IETF para intentar alcanzar una solucin. Tambin asistirn cerca de 40 representantes de operadores y proveedores de equipos de red. Una vez concluya el encuentro, la ITU-T enviar una carta a la directiva del IETF destacando las decisiones tomadas por el Working Party 3 acerca de las futuras directrices de T-MPLS. Todos los cambios que se produzcan en el estndar tendrn que ser plasmados en un borrador y se sometern a aprobacin en la prxima reunin plenaria del Study Group 15, que se celebrar en febrero de 2008.

El trmino MPLS (Conmutacin de etiquetas multiprotocolo) representa un conjunto de especificaciones definidas por el IETF (Grupo de Trabajo de Ingeniera de Internet) que le asigna a las tramas que circulan por la red una identificacin que le indique a los routers la ruta que deben seguir los datos. Por lo tanto, MPLS sirve para la administracin de la calidad de servicio al definir 5 clases de servicios, conocidos como CoS.
y y

Video. La clase de servicio para transportar video tiene un nivel de prioridad ms alto que las clases de servicio para datos. Voz. La clase de servicio para transportar voz tiene un nivel de prioridad equivalente al de video, es decir, ms alto que las clases de servicio para datos.

y y

Datos de alta prioridad (D1). sta es la clase de servicio con el nivel de prioridad ms alto para datos. Se utiliza particularmente para aplicaciones que son crticas en cuanto necesidad de rendimiento, disponibilidad y ancho de banda. Datos de prioridad (D2). Esta clase de servicio se relaciona con aplicaciones que no son crticas y que tienen requisitos particulares en cuanto a ancho de banda. Los datos no prioritarios (D3) representan la clase de servicio de prioridad ms baja.

Las especificaciones de MPLS operan en la capa 2 del modelo OSI y pueden funcionar particularmente en redes IP, ATM o frame relay.