The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Mar> msg00019



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

New TTL Draft

  • From: Eric Rosen <erosen@cisco.com>
  • Date: Thu, 01 Mar 2001 16:20:19 -0500
  • cc: akyol@akyol.org, djiang1@lucent.com, "B, Prakash K (Prakash)" <prakashk@lucent.com>, "'mpls@uu.net'" <mpls@UU.NET>
  • User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1(Nishinokyō) Emacs/20.6 (sparc-sun-solaris2.5.1)MULE/4.0 (HANANOEN)


Consider the following way of handling TTL at the push/pop points:

1. when a label  is pushed on a packet,  its TTL field is set  to either one
   less than the iTTL, OR to a configured value;

2. when a label is  popped off a packet, the TTL field  of the newly exposed
   label or IP  header is set to the  minimum of (a) one less  than the iTTL
   and (b) the existing value of the  field (this rule is needed in order to
   prevent a TTL from getting longer as a packet travels).

Then  the  pipe  model  can  be  provided by  having  a  sufficiently  large
configured value (e.g., 255) in  step 1 (given certain assumptions about the
length of the LSP). 

It's kind of heuristic, but it  usually works, it doesn't complicate the pop
processing any  more than  is absolutely necessary,  and it doesn't  rely on
signalling (only the head end needs to know the model). 

I believe there are certain implementations that work this way.