The MPLS WG Archive

["B, Prakash K (Prakash)" <prakashk@lucent.com>]

Hello Eric,
Assume an LSP comprises LSRs Ra, Rb, Rc and Rd with Ra as the ingress and Rd
as the eggress nodes and all of them are capable of TTL decrement.
There is a tunnel1 between Ra and Rb comprising LSRs R1, R2, R3 and R4.
Similarily, R5-R8 is the tunnel2 connecting Rc and Rd.
Rb and Rc are direct neighbours. R1 to R8 are ATM LSRs.

>From the above configuration, it follows that Ra is the ingress to tunnel1
whose eggress is Rb. Similarily Rc and Rd are the ingress and egress LSRs of
tunnel2.

If a packet enters this network, it encounters 12 nodes in all.

Will the TTL of the packet emerging from Rd be (Original TTL - 12) or should
it be simply(Original TTL - 4).??

TTL -4 will be the case if the tunnels are of Non TTL decrement type and one
of the feature claimed here is the concept of tunnels being oblivious to the
end user (possibly an IP cloud connected to Rd).

Do the same rules apply when the tunnels are capable of TTL decrement??

Regards,
Prakash

-----Original Message-----
From: Eric Gray [mailto:eric.gray@sandburst.com]
Sent: Tuesday, February 20, 2001 9:25 PM
To: B, Prakash K (Prakash)
Cc: 'mpls@uu.net'
Subject: Re: Hop Count Procedures


"B, Prakash K (Prakash)" wrote:

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

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