Network Working Group P. Agarwal Request for Comments: 3443 Brocade Updates: 3032 B. Akyol Category: Standards Track Cisco Systems January 2003 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. MPLS-ARCH, MPLS-ENCAPS], and that the methods presented in this document complement [MPLS-DS].
In particular, a new mode of operation (referred to as the Pipe Model) is introduced to support the practice of configuring MPLS LSPs such that packets transiting the LSP see the tunnel as a single hop regardless of the number of intermediary label switch routers (LSR). The Pipe Model for TTL is currently being used in multiple networks and is provided as an option configurable by the network operator by several vendors. This document formalizes the TTL processing in MPLS networks and ties it with the terminology introduced in [MPLS-DS]. MPLS-ENCAPS] only covers the Uniform Model and does NOT address the Pipe Model or the Short Pipe Model. This document addresses these two models and for completeness will also address the Uniform Model. b) [MPLS-ENCAPS] does not cover hierarchical LSPs. This document addresses this issue. c) [MPLS-ENCAPS] does not define TTL processing in the presence of Penultimate Hop Popping (PHP). This document addresses this issue. MPLS-ENCAPS], MPLS packets use a MPLS shim header that indicates the following information about a packet: a) MPLS Label (20 bits) b) TTL (8 bits) c) Bottom of stack (1 bit) d) Experimental bits (3 bits) The experimental bits were later redefined in [MPLS-DS] to indicate the scheduling and shaping behavior that could be associated with an MPLS packet. [MPLS-DS] also defined two models for MPLS tunnel operation: Pipe and Uniform Models. In the Pipe Model, a MPLS network acts like a circuit when MPLS packets traverse the network such that only the LSP ingress and egress points are visible to nodes that are outside the tunnel. A Short variation of the Pipe Model is also defined in [MPLS-DS] to differentiate between different egress forwarding and QoS treatments. On the other hand, the Uniform Model makes all the
nodes that a LSP traverses visible to nodes outside the tunnel. We will extend the Pipe and Uniform Models to include TTL processing in the following sections. Furthermore, TTL processing, when performing PHP, is also described in this document. For a detailed description of Pipe and Uniform Models, please see [MPLS-DS]. TTL processing in MPLS networks can be broken down into two logical blocks: (i) the incoming TTL determination to take into account any tunnel egress due to MPLS Pop operations; (ii) packet processing of (possibly) exposed packets and outgoing TTLs. We also note here that signaling the LSP type (Pipe, Short Pipe or Uniform Model) is out of the scope of this document, and that is also not addressed in the current versions of the label distribution protocols, e.g. LDP [MPLS-LDP] and RSVP-TE [MPLS-RSVP]. Currently, the LSP type is configured by the network operator manually by means of either a command line or network management interface. section 3.5 for exception). It is always (iTTL - 1) unless otherwise stated. oTTL Check: Check if oTTL is greater than 0. If the oTTL Check is false, then the packet is not forwarded. Note that the oTTL check is performed only if any outgoing TTL (either IP or MPLS) is set to oTTL (see section 3.5 for exception).
MPLS-ENCAPS]): ========== LSP =============================> +--Swap--(n-2)-...-swap--(n-i)---+ / (outer header) \ (n-1) (n-i) / \ >--(n)--Push...............(x).....................Pop--(n-i-1)-> (I) (inner header) (E or P) (n) represents the TTL value in the corresponding header (x) represents non-meaningful TTL information (I) represents the LSP ingress node (P) represents the LSP penultimate node (E) represents the LSP Egress node This picture shows TTL processing for a Uniform Model MPLS LSP. Note that the inner and outer TTLs of the packets are synchronized at tunnel ingress and egress. MPLS-DS]. In the Short Pipe Model, the forwarding treatment at the egress LSR is based on the tunneled packet, as opposed to the encapsulating packet.
section 3.6. For packets that are routed as MPLS, we have four cases: 1) Swap-only: The routed label is swapped with another label and the TTL field of the outgoing label is set to oTTL. 2) Swap followed by a Push: The swapped operation is performed as described in (1). The TTL value(s) of any pushed label(s) is determined as described in section 3.6. 3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL check should be performed irrespective of whether the oTTL is used to update the TTL field of the outgoing header. If the PHPed label belonged to a Short Pipe Model LSP, then the TTL field of the PHP exposed header is neither checked nor updated. If the
PHPed label was a Uniform Model LSP, then the TTL field of the PHP exposed header is set to the oTTL. The TTL value(s) of additional labels are determined as described in section 3.6 4) Pop: The pop operation happens before routing and hence it is not considered here. MPLS-ENCAPS, MPLS-DS]. In particular, the document does not define a new protocol or expand an existing one and does not introduce security problems into the existing protocols. The authors believe that clarification of TTL handling in MPLS networks benefits service providers and their customers since troubleshooting is simplified.
[RFC-2119] Bradner, S. "Key words for use in RFC's 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. [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.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.