Puneet Agarwal Internet Draft Bora A. Akyol Document: draft-agarwal-mpls-ttl-00.txt Pluris Category Informational Expires: August 2001 February 2001 TTL Processing in MPLS Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes 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]. 1. Introduction and Motivation This document describes TTL processing in hierarchical MPLS networks. We believe that this document adds details that have not been addressed in [MPLS-ARCH, MPLS-ENCAPS], and that the methods presented in this document complement [MPLS-DS]. 2. TTL Processing in MPLS Networks TTL Processing in MPLS Networks February 2001 2.1 Terminology and Background As defined in [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 a 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 conduit when MPLS packets traverse the network such that only the LSP ingress and egress points are visible to nodes that are outside the tunnel. 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 Penultimate Hop Pop (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 packet & outgoing TTL. 2.2 New Terminology iTTL: The TTL value to use as the incoming TTL. No checks are performed on the iTTL. oTTL: This is the TTL value used as the outgoing TTL value. 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. 2.3 Incoming TTL (iTTL) determination If the incoming packet is an IP packet, then the iTTL is the TTL value of the incoming IP packet. If the incoming packet is a MPLS packet and we are performing a Push/Swap/PHP, then the iTTL is the TTL of the topmost incoming label. TTL Processing in MPLS Networks February 2001 If the incoming packet is a MPLS packet and we are performing a Pop (tunnel termination), the iTTL is based on the tunnel type (Pipe or Uniform) of the LSP that was popped. If the popped label belonged to a Pipe model LSP, then the iTTL is the TTL of the label/IP-packet exposed after the label was popped. If the popped label belonged to a Uniform model LSP, then the iTTL is equal to the TTL of the popped label. If multiple Pop operations are performed sequentially, then the procedure given above is repeated with one exception: the iTTL computed during the previous Pop is used as the TTL of subsequent label being popped; i.e. the TTL contained in the subsequent label is essentially ignored and replaced with the iTTL computed during the previous pop. 2.4 Outgoing TTL Determination and Packet Processing After the iTTL computation is performed, the outgoing TTL of the (labeled) packet is calculated and packet headers are updated. If the packet was routed as an IP packet, the TTL value of the IP packet is set to oTTL (iTTL _ 1). The TTL value(s) for any pushed label(s) are determined as described in section 2.5. For packets that are routed as MPLS, we have three cases: 1) Swap-only: The routed label is swapped with another label and the TTL 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) are determined as described in section 2.5. 3) Penultimate Hop Pop (PHP): The routed label is popped. The oTTL check should be performed irrespective of whether the oTTL is used in any outgoing label/IP-header. The oTTL used for the TTL check is the unmodified oTTL (iTTL _1). If the PHPed label belonged to a Pipe model LSP, then the oTTL is set to the TTL of the PHP exposed IP-packet/label - but the TTL of the PHP exposed IP-header/label is NOT updated. If the PHPed label was a Uniform model LSP, then the TTL of the PHP exposed IP- header/label is set to the oTTL. The TTL values of additional labels are determined as described in Section 2.5. 2.5 Tunnel Ingress Processing (Push) For each pushed Uniform model label, the TTL is copied from the label/IP-packet immediately underneath it. For each pushed Pipe model label, the TTL field is set to a value configured by the network operator. In most implementations, this value is set to 255 by default. TTL Processing in MPLS Networks February 2001 3. Conclusion This Internet Draft describes how TTL field can be processed in a MPLS network. We clarified the various methods that are applied in the presence of hierarchical tunnels and completed the integration of Pipe and Uniform models with TTL processing. 4. Security Considerations This document does not add any new security issues other than the ones defined in [MPLS-ENCAPS, MPLS-DS]. 5. References [MPLS-ARCH] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture," RFC 3031. [MPLS-ENCAPS] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, "MPLS Label Stack Encoding," RFC3032. [MPLS-DS] F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen, "MPLS Support of Differentiated Services," draft-ietf-mpls-diff-ext-07.txt. (Work in progress) Author's Addresses Puneet Agarwal Pluris 10455 Bandley Drive Cupertino, CA 95014 Email: puneet@pluris.com Bora Akyol Pluris 10455 Bandley Drive Cupertino, CA 95014 Email: akyol@akyol.org Expiration This document will expire in August 2001.