Subject: RE: Hop Count Procedures

From: [email-masked]
Date: Wed, 21 Feb 2001 08:38:19 -0500

Hi Prahash,

I believe the TTL in your case should be deducted by 12 instead of 4.   12
is the number of routers the traffic has been through.  There should be no
reason to deduct less that 12.  It should not matter whether the traffic
was tunneled or not.

Regards,
Jane D. Jiang

"B, Prakash K (Prakash)" <[email-masked]>@UU.NET on 02/21/2001
01:15:28 AM

Sent by:  [email-masked]

To:   "'Eric Gray'" <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>
Subject:  RE: Hop Count Procedures

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 13:07:28 -0500

Jane,

    See my reply to Prakash.

    Essentially, the issue is that it is not necessarily how
many routers a packet goes through as how many you
want (or have) to make it seem like the packet goes through.

    More is not always better.

--
Eric Gray

---

From: Bora Akyol <[email-masked]>
Date: Fri, 23 Feb 2001 07:48:35 -0800

Note that we (Puneet and I) just posted an Internet Draft on TTL 
handling in hierarchical MPLS networks.

The internet draft is titled: draft-agarwal-mpls-ttl-00.txt

http://search.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-00.txt

We welcome any comments,

Bora Akyol

---

From: Eric Gray <[email-masked]>
Date: Fri, 23 Feb 2001 12:34:02 -0500

Bora/Puneet,

    Some comments.

    In section 2.4, item 3 - PHP does not necessarily expose an
IP header.  The text in this section is not clear in this respect
- possibly because of the textual construct "IP-Header/label".
It might be somewhat clearer if you use "header" and add a
paragraph stating that the PHP exposed header may be either
an IP header or an MPLS label and the appropriate oTTL  is
written to the corresponding TTL field of this PHP exposed
header.

    Also, in this section, why is oTTL set to the TTL of the
exposed header if it is not used for anything?

    In addition, if your actually specifying a behavior (rather than
an architecture), I believe you need to allow that the TTL may
be decremented by a number other than one.  RFC 791 states
that RFC is decremented by at least one.  Your draft states in
several places that iTTL is decremented (I assume that the
underscore in these cases is meant to be a minus sign) by one.

    There are practical reasons for decrementing TTL by more
than one (a high-cost or low-bandwidth link, for example)
when it is desirable to accelerate the aging of possibly looping
packets.  A higher TTL decrement punishes all packets that use
the link, but it punishes looping packets much more.

    Finally, what is the mechanism which the PHP uses to determine
whether or not the LSP is using the pipe or the uniform model?  I am
not sure this information is currently available.

--
Eric Gray