Network Working Group P. Agarwal Request for Comments: 3443 Brocade Updates: 3032 B. Akyol Category: Standards Track Cisco Systems Enero 2003 Procesamiento del Tiempo de Vida (TTL) en Redes MPLS (Multi-Protocol Label Switching) Estado de este documento Este documento especifica un protocolo estándar de Internet para la comunidad de Internet y solicita discusión y sugerencias para mejorar. Vea la edición actual del "Internet Official Protocol Standards" (STD 1) para el estado de estandarización y estado de este protocolo. La distribución de este documento es ilimitada. Copyright Notice Copyright (C) The Internet Society (2003). Todos los derechos reservados. Resumen Este documento describe el procesamiento del Tiempo de Vida (TTL) en las redes jerárquicas MPLS (Multi-Protocol Label Switching) y está motivado por la necesidad de formalizar un modo de operación transparente al Tiempo de Vida (TTL) para un camino de conmutación de etiqueta MPLS. Actualiza la RFC 3032, "MPLS Label Stack Encoding". Los procesamientos del TTL en los túneles jerárquicos con Modelo Pipe [tubería] y Uniforme se especifican con ejemplos tanto para los casos "push" como los "pop". También el documento complementa la RFC 3270, "MPLS Support of Differentiated Services" y liga juntos la terminología introducida en este documento con el procesamiento del TTL en redes jerárquicas MPLS. Convenciones usadas en este documento Las palabras "DEBE", "NO DEBE", "REQUERIDO", "HARÁ", "NO HARÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" se deben interpretar tal y como describe el [RFC-2119]. 1. Introducción y Motivación Este documento describe el procesamiento del Tiempo de Vida (TTL) en las redes jerárquicas MPLS. Creemos que este documento añade detalles que no se han tratado en [MPLS-ARCH, MPLS-ENCAPS], y que los Agarwal & Akyol Estándar [Página 1] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 métodos presentados en este documento complementan [MPLS-DS]. En particular, un nuevo modo de operación (referido como el Modelo Pipe) se introduce para soportar la práctica de la configuración de los caminos LSP de MPLS tales como los paquetes que transitan por el camino LSP viendo el túnel como un solo salto indiferente al número de enrutadores intermedios de conmutación de etiquetas (LSR). El Modelo Pipe para TTL se utiliza actualmente en múltiples redes y se proporciona como una opción configurable para el operador de la red por varios fabricantes. Este documento formaliza el procesamiento TTL en redes MPLS y lo relaciona con la terminología introducida en [MPLS-DS]. 2. Procesamiento TTL en redes MPLS 2.1. Cambios al RFC 3032 [MPLS-ENCAPS] a) [MPLS-ENCAPS] solo cubre el Modelo Uniforme y NO se trata el Modelo Pipe ni el Modelo Short Pipe. Este documento trata estos dos modelos y para que quede completo también se trata el Modelo Uniforme. b) [MPLS-ENCAPS] no cubre los caminos jerárquicos LSP. Este documento contempla esta cuestión. c) [MPLS-ENCAPS] no define el procesamiento TTL en la presencia de PHP (Penultimate Hop Popping). Este documento contempla esta cuestión. 2.2. Terminología y Antecedentes Como se definió en [MPLS-ENCAPS], los paquetes MPLS usan una cabecera "shim" MPLS que indica la siguiente información relativa al paquete: a) Etiqueta MPLS (20 bits) b) TTL (8 bits) c) Fondo de la pila (1 bit) d) Bits experimentales (3 bits) Los bits experimentales fueron más tarde redefinidos en [MPLS-DS] para indicar el comportamiento de programación y modulación que se puede asociar a un paquete MPLS. [MPLS-DS] también definió dos modelos para la operación con túnel MPLS: Modelos Pipe y Uniforme. En el Modelo Pipe, una red MPLS actúa como un circuito cuando los paquetes MPLS atraviesan la red de forma que sólo los puntos de entrada y salida del camino LSP son visibles a Agarwal & Akyol Estándar [Página 2] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 los nodos fuera del túnel. Una variación Short del Modelo Pipe también se define en [MPLS-DS] para diferenciar entre distintas salidas de envío y tratamientos QoS. Por otro lado, el Modelo Uniforme hace que todos los nodos que atraviesa un camino LSP sean visibles a los nodos fuera del túnel. Nosotros extendemos los Modelos Pipe y Uniforme para incluir el procesamiento TTL en las secciones siguientes. Además el procesamiento TTL, cuando se realiza PHP (Penultimate Hop Popping), también se describe en este documento. Para una descripción detallada de los Modelos Pipe y Uniforme, por favor, vea [MPLS-DS]. El procesamiento TTL en las redes MPLS se puede desglosar en dos bloques lógicos : (i) la determinación de entrada TTL para tener en cuenta cualquier túnel de salida debido a las operaciones Pop MPLS; (ii) procesamiento del paquete de los paquetes (posiblemente) expuestos y los TTL salientes. También notamos aquí que la señalización tipo LSP (Modelo Pipe, Short Pipe o Uniforme) está fuera del objetivo de este documento, que tampoco se trata em las versiones actuales de los protocolos de distribución de etiquetas, p.e. LDP [MPLS-LDP] y RSVP-TE [MPLS-RSVP]. Habitualmente el tipo LSP es configurado manualmente por el operador de red por medio de la linea de comando o una interface de gestión de red. 2.3. Nueva Terminología iTTL: El valor TTL a usar como TTL de entrada. No se hacen comprobaciones del iTTL. oTTL: Este es el valor TTL usado como TTL de salida (ver la sección 3.5 para excepciones). Es siempre (iTTL - 1) a menos que se diga lo contrario. Comprobación oTTL: Comprobación de si oTTL es mayor que 0. Si la comprobación oTTL es falsa, entonces el paquete no es enviado. Notemos que la comprobación oTTL se realiza únicamente si cualquier TTL de salida (IP o MPLS) está marcado como oTTL (ver sección 3.5 para excepciones). 3. Procesado del TTL en diferentes Modelos Esta sección describe el procesado del TTL pra los caminos LSP de acuerdo con los 3 modelos (Uniforme, Short Pipe y Pipe) en la presencia/ausencia de PHP (Penultimate Hop Popping) (donde sea aplicable). 3.1. Procesado del TTL en el Modelo Uniforme de los caminos LSP (con o Agarwal & Akyol Estándar [Página 3] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 sin PHP) (consistente con [MPLS-ENCAPS]): ========== LSP =============================> +--Swap--(n-2)-...-swap--(n-i)---+ / (cabecera exterior) \ (n-1) (n-i) / \ >--(n)--Push...............(x).....................Pop--(n-i-1)-> (I) (cabecera interior) (E o P) (n) representa el valor TTL en la correspondiente cabecera (x) representa la información no significativa del TTL (I) representa el nodo de entrada del camino LSP (P) representa el penúltimo nodo del camino LSP (E) representa el nodo de salida del camino LSP La figura muestra el procesado del TTL en el Modelo Uniforme del camino LSP de MPLS. Nótese que los TTLs interior y exterior de los paquetes están sincronizados en el túnel de entrada y salida. 3.2. Procesado de TTL para LSPs en el Modelo Short Pipe 3.2.1. Procesado de TTL para LSPs en el Modelo Short Pipe sin PHP ========== LSP =============================> +--Swap--(N-1)-...-swap--(N-i)-----+ / (cabecera exterior) \ (N) (N-i) / \ >--(n)--Push...............(n-1).....................Pop--(n-2)-> (I) (cabecera interior) (E) (N) representa el valor TTL (puede que no hayan relaciones a n) (n) representa el valor TTL del túnel en la cabecera encapsulada (I) representa el nodo de entrada del camino LSP (E) representa el nodo de salida del camino LSP El Modelo Short Pipe fue introducido en [MPLS-DS]. En el Modelo Short Pipe, el tratamiento de envío al enrutador LSR de salida se basa en el paquete tunelado, como opuesto al paquete encapsulado. 3.2.2. Procesado de TTL para LSP en el Modelo Short Pipe con PHP: Agarwal & Akyol Estándar [Página 4] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 ========== LSP =====================================> +-Swap-(N-1)-...-swap-(N-i)-+ / (cabecera exterior) \ (N) (N-i) / \ >--(n)--Push.............(n-1)............Pop-(n-1)-Decr.-(n-2)-> (I) (cabecera interior) (P) (E) (N) representa el valor TTL (puede ser que no tenga relación con n) (n) representa el valor TTL del túnel en la cabecera encapsulada (I) representa el nodo de entrada del camino LSP (P) representa el penúltimo nodo del camino LSP (E) representa el nodo de salida del camino LSP. Como la etiqueta ya se ha extraído por el penúltimo nodo del LSP, el nodo de salida del camino LSP simplemente decrementa el TTL de la cabecera. Nótese también que al final del LSP del Modelo Short Pipe, el TTL del paquete tunelado ha sido decrementado en dos, con o sin PHP. 3.3. Procesado de TTL en los caminos LSP con Modelo Pipe (sin PHP solamente): ========== LSP =============================> +--Swap--(N-1)-...-swap--(N-i)-----+ / (cabecera exterior) \ (N) (N-i) / \ >--(n)--Push...............(n-1)....................Pop--(n-2)-> (I) (cabecera interior) (E) (N) representa el valor TTL (puede ser que no tenga relación con n) (n) representa el valor TTL del túnel en la cabecera encapsulada (I) representa el nodo de entrada del camino LSP (E) representa el nodo de salida del camino LSP Desde la perspectiva del TTL, el trato de un camino LSP con Modelo Pipe es idéntico al del Modelo Short Pipe sin PHP. 3.4. Determinación del TTL de Entrada (iTTL) Si el paquete de entrada es un paquete IP, entonces el iTTL es el valor TTL del paquete de entrada IP. Si el paquete de entrada es un paquete MPLS y estamos realizando un Push/Swap/PHP, entonces el iTTL es el TTL de la etiqueta de entrada Agarwal & Akyol Estándar [Página 5] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 de más arriba de la pila. Si el paquete de entrada es un paquete MPLS y estamos realizando un Pop (final del túnel), el iTTL se basa en el tipo de túnel (Pipe o Uniforme) del camino LSP que fue sacado. Si la etiqueta sacada pertenece a un camino LSP con Modelo Pipe, entonces el iTTL es el valor del campo TTL de la cabecera, expuesto después de que la etiqueta fue sacada (notemos que para el objetivo de este documento, la cabecera expuesta puede o ser una cabecera IP o una etiqueta MPLS). Si la etiqueta sacada pertenecía a un camino LSP con Modelo Uniforme, entonces el iTTL es igual al TTL de la etiqueta sacada. Si se realizan secuencialmente múltiples operaciones Pop, entonces el procedimiento anterior se repite con una excepción: el iTTL calculado durante el Pop previo se usa como el TTL de la etiquetas posteriores que son sacadas; p.e. el TTL contenido en la etiqueta posterior se ignora esencialmente y se sustituye con el iTTL computado durante el pop previo. 3.5. Determinación del TTL de salida y el Procesamiento del Paquete Después de haberse calculado el iTTL, se realiza la comprobación del oTTL. Si la comprobación del oTTL es satisfactoria, entonces del TTL de salida del paquete (etiquetado/sin etiquetar) es calculado y las cabeceras del paquete son actualizadas como se define más abajo. Si el paquete fue enrutado como un paquete IP, el valor del TTL del paquete IP es puesto a oTTL (iTTL - 1). El(los) valor(es) del TTL para cualquier etiqueta(s) puesta(s) se determina como se describe en la sección 3.6. Para los paquetes que son enrutados como MPLS, tenemos cuatro casos: 1) Swap-only: La etiqueta enrutada es canjeada con otra etiqueta y el campo TTL de la etiqueta de salida es puesta a oTTL. 2) Swap seguido por un Push: La operación de canje se realiza como se describe (1). El(los) valor(es) de TTL de cualquier etiqueta(s) puesta(s) se determina como se describe en la sección 3.6. 3) Penúltimo Hop Pop (PHP): La etiqueta enrutada es sacada. La comprobación de oTTL se realizaría sin tener en cuenta de si el oTTL se usa para actualizar el campo TTL de la cabecera de salida. Si la etiqueta PHP pertenece a un camino LSP con Modelo Short Pipe, entonces el campo TTL de la cabecera expuesta del PHP no es ni comprobada ni actualizada. Si la etiqueta PHP era de un camino LSP con Modelo Uniforme, entonces el campo TTL de la cabecera expuesta PHP es puesta a oTTL. El(los) valor(es) TTL de las etiquetas adicionales se determina como se describe en la sección Agarwal & Akyol Estándar [Página 6] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 3.6 4) Pop: La operación pop sucede antes del enrutamiento y por lo tanto no se considera aquí. 3.6. Procesamiento del Túnel de Entrada (Push) Para cada etiqueta puesta del Modelo Uniforme, el TTL se copia de la etiqueta/paquete IP inmediatamente bajo suyo. Para cada etiqueta puesta del Modelo Pipe o Short Pipe, el campo TTL se pone a un valor configurado por el operador de la red. En la mayoría de las implementaciones, este valor se pone a 255 de forma predeterminada. 3.7. Notas de Implementación 1) Aunque iTTL se puede decrementar por un valor mayor que 1 mientras está siendo actualizado o está siendo determinado oTTL, esta característica solo sería usada para compensar los nodos de la red que no son capaces de decrementar los valores TTL. 2) Cuando se decrementa iTTL, el implementador debe estar seguro que el valor no resulte negativo. 3) En el Modelo Short Pipe con disponibilidad PHP, el TTL del paquete tunelado no cambia después de la operación PHP. 4. Conclusión Este Documento de Internet describe cómo el campo TTL puede ser procesado en una red MPLS. Clarificamos varios métodos que se aplican en la presencia de túneles jerárquicos y completamos la integración de los Modelos Pipe y Uniforme con el procesado TTL. 5. Consideraciones de Seguridad Este documento no añade nuevas cuestiones de seguridad distintas de las definidas en [MPLS-ENCAPS, MPLS-DS]. En particular, el documento no define un nuevo protocolo ni amplía uno existente y no introduce problemas de seguridad en los protocolos existentes. Los autores creen que la clarificación del manejo del TTL en las redes MPLS beneficia a los proveedores de servicios y sus clientes ya que se simplifica la resolución de los problemas. 6. Referencias 6.1. Referencias Normativas Agarwal & Akyol Estándar [Página 7] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 [RFC-2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-DS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. 6.2. Referencias Informativas [MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001. [MPLS-RSVP] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 7. Reconocimientos A los autores les gustaría agradecer a los miembros de grupo de trabajo del MPLS por sus comentarios. Especialmente agradecer a Shahram Davari y Loa Andersson por su cuidadosa revisión del documento y sus comentarios. 8. Direcciones de los Autores Puneet Agarwal Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 EMail: puneet@acm.org Bora Akyol Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 EMail: bora@cisco.com 9. Declaración Completa de Copyright Agarwal & Akyol Estándar [Página 8] RFC 3443 Procesamiento del TTL en redes MPLS Enero 2003 Copyright (C) The Internet Society (2003). Todos los derechos reservados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y los trabajos derivados que lo comentan o lo explican o ayudan a su implementación pueden ser preparados, copiados, publicados y distribuídos, enteros o en parte, sin restricción de ningún tipo, siempre que se incluyan este párrafo y la nota de copyright expuesta arriba en todas esas copias y trabajos derivados. Sin embargo, este documento en sí no debe ser modificado de ninguna forma, tal como eliminando la nota de copyright o referencias a la necesario en el desarrollo de estándares Internet, en cuyo caso se seguirán los procedimientos para copyrights definidos en el proceso de Estándares Internet, o con motivo de su traducción a otras lenguas aparte del Inglés. Los limitados permisos concedidos arriba son perpetuos y no serán revocados por la Internet Society ni sus sucessores o destinatarios. Este documento y la información contenida en él se proporcionan en su forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECIFICO. Reconocimiento En la actualidad, la financiación para las funciones del editor RFC es proporcionada por la Internet Society. Agarwal & Akyol Estándar [Página 9]