Subject: Re: New TTL Draft.

From: Vishal Mishra <[email-masked]>
Date: Tue, 6 Mar 2001 11:53:48 -0800

Hello All,

    Besides the reasons specified below, there are several other situations
in which it is desirable to decrement TTL by N.

    According to the MPLS architecture, any label distribution protocol can
be used for LSP setup. Therefore, assume an 
MPLS cloud, which is built over IP (no ATM/Frame Relay for now). Let us also
assume that this MPLS cloud is composed
of LSRs that use RSVP and/or LDP as their Label Distribution (and therefore
LSP setup) Protocols.

    Now an administrator wants to setup an LSP using RSVP, but realizes that
the path is passing through a non-RSVP 
(say LDP) cloud.

    Since IP-TTL counts the number of IP hops, and RSVP-TTL counts the
number of RSVP hops, therefore the presence of a 
Non-RSVP cloud is detected by the next RSVP hop, and LSP setup fails, with
Path Tear messages being replied back to the 
sender(s).

     Therefore, now the administrator would like to connect the RSVP clouds
with a 'Single IP Hop' LSP so that, To RSVP, the
Multi-MPLS-Hop LSP 'looks' like a Single-IP-Hop. To achieve this, the
Ingress LER should be able to setup the LSP, and 'tell'
the Egress, not to copy MPLS-TTL into IP-TTL. Instead, it (Ingress LER)
would be decrementing the TTL by N  (In this 
example: N=1, by configuration).

     Do we have any mechanism in RSVP and/or LDP to configure/negotiate the
'IP-Hop length' (say N) of an LSP, so that 
Ingress LER decrements the IP TTL (by N), and Egress LER does not copy
MPLS-TTL into IP-TTL ? I don't think so,
although it can be done at the time of LSP setup.

     If this needs to be supported in RSVP and LDP, then for RSVP, we would
need a new 'OPTIONAL' RSVP object 
(say IP_HOP_LENGTH), and for LDP, we would need a new 'OPTIONAL' TLV (say
IP_HOP_LENGTH).

    I feel that the potential of MPLS TTL field is not being fully utilized
by the existing MPLS mechanisms. e.g. We can
control the 'perceived' length of an LSP using the above proposed mechanism.
There lies the power of MPLS ;-), and
the value addition of the presence of multiple TTL fields in the
MPLS-IP-Packet !!

    Awaiting Comments ...

Vishal.

--- Francis Arts <[email-masked]> wrote:
> 
> Hello Eric,
> 
> In the discussion below you propose the possibility to decrement the TTL
> with N units. You indicate that the reason for doing this, is the
following:
>> 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.

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

---

From: Vishal Mishra <[email-masked]>
Date: Tue, 6 Mar 2001 11:53:48 -0800

Hello All,

    Awaiting Comments ...

Vishal.