The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Yousuf,

    Actually, this is not a 'no-decrement-TTL' option in the strictest
sense - which should alleviate a lot of concerns.  TTL is decremented
at the ingress LSR (possibly even before it knows it is an ingress LSR)
before a label is pushed onto the stack (creating the stack if necessary).
The as-decremented TTL may then be copied to the new label stack entry
as a starting point for the LSP itself.  Note that this is the expected
behavior, but the actual value used is not important if the egress will
ignore the final TTL value for the LSP when packets are egressed.  In
the 'pipe' analog the as-decremented TTL is then unchanged at the egress
while, in the 'uniform' analog, the as-decremented TTL is over-written by
the further decremented TTL in the encapsulation being popped.

    Note that, as far as TTL is concerned, the only currently defined
behavior is the 'uniform' analog.  People who do not wish to support it
need do (and should do) nothing.  Those people who wish to support the
'pipe' analog will need to define how the ingress and egress can be in
synchronization about how TTL will be processed at the egress.  This can
be done via configuration at each end of every affected LSP, or it may
be accomplished by configuration at the ingress and signaling.  Last time
I heard from Bora and Puneet, their proposal included signaling.

--
Eric Gray

You wrote:

> Also, the default is to decrement the MPLS TTL, so as pointed out by Anoop the feature to not decrement MPLS TTL to make the LSP look like a single-hop is a knob only
> Thanks
>
> -Yousuf
>
> At 11:49 AM 8/21/2001 -0700, Ray Qiu wrote:
> >Anoop,
> >
> >The no-decrement-TTL option making the LSP appear as a one-hop router to
> >diagnostic tools.  This feature can be turned on per LSP.  So it gives you the flexibility.
> >
> >Also, you gave us a routing loop example, that should not happen all the
> >time, right?  :)  So I really don't think it will affect your network
> >performance.
> >
> >Thanks,
> >Ray
> >
> >On Tue, 21 Aug 2001, Anoop Ghanwani wrote:
> >
> >> Date: Tue, 21 Aug 2001 11:27:57 -0700
> >> From: Anoop Ghanwani <anoop@cosinecom.com>
> >> To: 'Ray Qiu' <rayq@riverstonenet.com>, Eric W Gray <ewgray@mindspring.com>
> >> Cc: Alexander Marhold <alexander@marhold.at>,
> >>      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> >> Subject: RE: Time to live
> >>
> >>
> >> I think that's a really bad idea.  TTL is there to
> >> protect the network from packets that might be in a loop.
> >> Nesting TTLs to that the outer one is used within the
> >> tunnel while the inner one stays the same could
> >> delay the time the it takes for TTL to protect the packet.
> >>
> >> For instance, consider the following topology.
> >>
> >> r1 -- r2 -- r3 -- r4 -- r5
> >>        |                 |
> >>       r9 -- r8 -- r7 -- r6
> >>
> >> Let's say the path from r3 to r8 is implemented by a
> >> tunnel (in pipe mode).  The packet first hits r2, enters
> >> the tunnel at r3, and then gets to r8. r3-r8 is treated as
> >> a single hop because the TTL in the IP header is only
> >> decremented by 1.  In this example the looping packet
> >> gets to traverse the loop many more times than it
> >> would have if we were just operating on TTL as specified
> >> in RFC 3032 (> 60 times versus < 30 times).
> >>
> >> Thus far, the argument in favor of hiding TTL has been
> >> that it helps hide the network topology and gives the user
> >> a perception of traversing fewer hops.  It seems like
> >> a lame reason because the real measure of performance
> >> is actually latency.
> >>
> >> Just my $0.02 ;-)
> >> -Anoop
> >>
> >>
> >> > -----Original Message-----
> >> > From: Ray Qiu [ mailto:rayq@riverstonenet.com
> >> <mailto:rayq@riverstonenet.com> ]
> >> > Sent: Tuesday, August 21, 2001 10:26 AM
> >> > To: Eric W Gray
> >> > Cc: Alexander Marhold; MultiProtocol Label Switching Mailing List
> >> > Subject: Re: Time to live
> >> >
> >> >
> >> > There is also an option that we don't copy the MPLS TTL back
> >> > to IP TTL.
> >> > It makes IP think the MPLS LSP is only one hop.
> >> >
> >> > Thanks,
> >> > Ray
> >> >
> >> > On Tue, 21 Aug 2001, Eric W Gray wrote:
> >> >
> >> > > Date: Tue, 21 Aug 2001 13:10:17 -0400
> >> > > From: Eric W Gray <ewgray@mindspring.com>
> >> > > To: Alexander Marhold <alexander@marhold.at>,
> >> > >      MultiProtocol Label Switching Mailing List <mpls@UU.NET>
> >> > > Subject: Re: Time to live
> >> > >
> >> > > Below, the last sentence was supposed to be "Note that Frame
> >> > > Relay ..."
> >> > >
> >> > > --
> >> > > Eric Gray
> >> > >
> >> > > Eric W Gray wrote:
> >> > >
> >> > > > Alexander,
> >> > > >
> >> > > >     No cigar.  The distinction is not cell verses frame,
> >> > but rather
> >> > > > whether or not it is possible to incorporate the label in the L2
> >> > > > encapsulation.  Where this is possible, ATM and FR, there is
> >> > > > no TTL capability in the L2 encapsulation.  Not that Frame
> >> > > > Relay is Frame based...
> >> > > >
> >> > > > --
> >> > > > Eric Gray
> >> > > >
> >> > > > You wrote:
> >> > > >
> >> > > > > Hello
> >> > > > > I want to explain the mechanism a little bit more in detail
> >> > > > >
> >> > > > > FRAME based general:
> >> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> >> > into the TTL-field of
> >> > > > > the label header.
> >> > > > > 2. the label-TTL is decremented at each hop by 1
> >> > > > > 3. when it reaches 0 the labelled packet will be dropped and a
> >> > > > > TTL-exceeded-ICMP message will be sent if possible
> >> > > > > 4. at the egress the label-TTL is copied back into the IP-TTL
> >> > > > >
> >> > > > > CELL based general:
> >> > > > > 1. normally at the ingress LSR the IP-TTL is copied
> >> > into the TTL-field of
> >> > > > > the label header.
> >> > > > > 1a. the ingress LSR to the ATM-MPLS cloud either
> >> > decrements the TTL by 1
> >> > > > > 1b              or by the amount of ATM_MPLS hops of
> >> > the LSP ( this he knows from the
> >> > > > > LSP-setup using downstream on demand label allocation
> >> > and ordered
> >> > > > > lsp-control label setup)
> >> > > > > 2. then the packet is chopped into cells
> >> > > > > 3. the egress reassembles the packet and copies the
> >> > label ttl back into the
> >> > > > > IP-TTL
> >> > > > >
> >> > > > > if 1a is used then the ATM-MPLS cloud looks like a 1-hop network
> >>
> >> > > > >
> >> > > > > special features:
> >> > > > > a) on cisco LSRs there is the possibility to disable
> >> > the copying of the
> >> > > > > IP-TTL to the label-TTL and the label-TTL again starts at 255.
> >> > > > > on the egress the smaller of the 2 TTL-values ( label
> >> > and IP-header) will be
> >> > > > > used for the IP-TTL
> >> > > > > then for traceroute the MPLS cloud looks like a 1-hop
> >> > (2-hop with PHP)
> >> > > > > network
> >> > > > >
> >> > > > > with best regards
> >> > > > >
> >> > > > > Alexander
> >> > > > >
> >> > > > > __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> >> > > > >      __/
> >> > > > >     __/   Dipl.Ing. Alexander Marhold MBA
> >> > > > >    __/   CCIE #3324, CCNP, CCDP, CCSI #20642
> >> > > > >   __/   Core & IP Services <Senior Consultant>
> >> > > > >  __/   Mobile: ++43-(0)664-16 28 234
> >> > > > > __/   PRO IN http://www.proin.com <http://www.proin.com>
> >> > > > >
> >> > > > > -----Original Message-----
> >> > > > > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET
> >> <mailto:owner-mpls@UU.NET> ]On Behalf Of
> >> > > > > Asim.Khan@vf.vodafone.co.uk
> >> > > > > Sent: Tuesday, August 21, 2001 6:22 PM
> >> > > > > To: c-david.escobar@wcom.com
> >> > > > > Cc: mpls@UU.NET
> >> > > > > Subject: RE: Time to live
> >> > > > >
> >> > > > > It stays the same. The routers only look at the label
> >> > value not the IP
> >> > > > > header. When the packet leaves MPLS domain then the
> >> > normal operation would
> >> > > > > apply.
> >> > > > >
> >> > > > > Asim
> >> > > > >
> >> > > > > -----Original Message-----
> >> > > > > From: David Escobar [ mailto:c-david.escobar@wcom.com
> >> <mailto:c-david.escobar@wcom.com> ]
> >> > > > > Sent: 21 August 2001 17:19
> >> > > > > To: mpls@UU.NET
> >> > > > > Subject: Time to live
> >> > > > >
> >> > > > > Hi;
> >> > > > > What happens to the TTL field in the IP header when a
> >> > labeled packet goes
> >> > > > > through an LSP? Is it decreased at each router or stay the same?
> >>
> >> > >
> >> >
> >> ########################################################################
> >> ############################## This email communication may contain
> >> CONFIDENTIAL INFORMATION and is intended only for the use of the
> >> intended recipients identified above.  If you are not the intended
> >> recipient of this communication, you must not use, disclose, distribute,
> >> copy or print this email. If you have received this communication in
> >> error, please immediately notify the sender by reply email, delete the
> >> communication and destroy all copies.
> >> ########################################################################
> >> ##############################
> >>
> >>