Subject: Hop Count Procedures

From: "B, Prakash K (Prakash)" <[email-masked]>
Date: Tue, 20 Feb 2001 15:25:56 +0530

ATM LSRS do not perform TTL decrement. RFC 3036 says that while propogating
the label mapping message upstream, if an LSR (Rd) finds out that its
upstream LSR (Ru) is a part of domain that does not perform TTL
decrement(ATM segment), it must reset the Hop Count value to 1. Will this
not lead to erroneous computation of final TTL in the long run when the
packet exits out of MPLS domain?Will not the true Hop count value assist the
ingress in determining in advance the TTL value that must be, when the
packet emerges out of a Non -TTL-decrement segment?

RFC 3031 clearly states that the final TTL value must reflect the true
number of hops that a packet takes to exit a MPLS domain .
Clarification solicited.

Prakash K.B.

---

From: Eric Gray <[email-masked]>
Date: Tue, 20 Feb 2001 10:55:19 -0500

> number of hops that a packet takes to exit a MPLS domain .

Prakash,

    The intention is to allow the ATM ingress LSR to be able to
decrement the TTL by the value of the hop count in LSP setup
messages used to establish an LSP that will be used to forward
data.  Note that the ATM ingress LSR does not have to do this,
but it could (if configured to do so, for instance, by the network
operator).

    In other words, when the ingress ATM LSR is about to put a
packet on a specific LSP, one of the things that it should get in
the FTN lookup is the decrement value for the packet's TTL.
The source of this value may be the hop count received in the
LSP setup messages.  This will be the case if the operator
intends their ATM "tunnel" to be apparent to the end user.

    Once the packet arrives at the egress from the ATM cloud,
the next hop will decrement the TTL by some non-zero value
and this will happen for each of the non-ATM LSRs in the
remainder of the LSP - up to and including the hop count of
the LSP setup.

    If the hop count was not reset to 1 by the LSR at the egress
from the ATM cloud (instead, reflecting all of the hops in the
LSP downstream), the result would be to (possibly) decrement
the TTL of packets arriving at the ingress to the ATM cloud by
the number of hops in the entire LSP and then decrementing it
again at every non-ATM LSR hop.

    This could cause premature packet demise.

--
Eric Gray