Subject: RE: Hop Count Procedures

From: "B, Prakash K (Prakash)" <[email-masked]>
Date: Wed, 21 Feb 2001 11:45:28 +0530

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:[email-masked]]
Sent: Tuesday, February 20, 2001 9:25 PM
To: B, Prakash K (Prakash)
Cc: [email-masked]'
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

---

From: Eric Gray <[email-masked]>
Date: Wed, 21 Feb 2001 11:30:36 -0500

Prakash,

    The reason for decrementing TTL is to prevent packets
from endlessly looping.  Hence technologies which do not
support decrementing TTL need to provide another means
for loop prevention or mitigation.  If a technology provides
- for example - a mechanism to prevent loop formation in
LSPs, then the network may gain very little from having
accelerated aging.  In fact, the prevalence of accelerated
aging tends to lead to higher initial TTL values in the
network off-setting at least some of the benefits expected
in networks which use TTL exclusively.

    So there are two questions the network operator has to
ask themselves:

    1)    do they want to treat the tunnel as a link?
and
    2)    can they do this without harming the network?

In some cases, not treating a tunnel as a link can harm the
network.  For example, in the not too distant past, initial
TTL values were set fairly low in some operating systems.
During that time, all it took was for a service provider to
insert one more router in the transit network and suddenly
numerous network destinations were no longer reachable.
In an ideal world, there should not be a detrimental impact
on the service being provided as a result of deliberate
changes in the network infrastructure.

The networking community's response to this was to
increase the default TTL in their operating systems by
as much as a factor of 8 - thus increasing the impact
of looping traffic (originating  from these hosts) on the
network by a factor of between 2 and 4.

However, it is not safe to treat a tunnel as a link if it can
be arbitrarily long (for example - as a result of the fact
that it can have transient looping).  It may also be unsafe
to treat a tunnel as a link if its egress can change without
detection at the ingress - however this can happen in an
L2 network with a real L3 link, so it is not really clear just
how unsafe this is.  I would think it is much less safe in a
network where this can happen fairly often.

So, I would say that you cannot compare the use of TTL
in tunneling across a network technology that does not
support decrementing TTL with the use of TTL in other
network technologies.

--
Eric Gray