Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
RFC 3443

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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.

Abstract

   This 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].

1. Introduction and Motivation

   This document describes Time To Live (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].

Agarwal & Akyol             Standards Track                     [Page 1]
RFC 3443            TTL Processing in MPLS Networks         January 2003

   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].

2. TTL Processing in MPLS Networks

2.1. Changes to RFC 3032 [MPLS-ENCAPS]

   a) [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.

2.2. 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 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

Agarwal & Akyol             Standards Track                     [Page 2]
RFC 3443            TTL Processing in MPLS Networks         January 2003

   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