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 Networks2.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
datatracker.ietf.org