Subject: RE: Processing the MPLS TTL

From: Shahram Davari <[email-masked]>
Date: Mon, 4 Dec 2000 04:59:35 -0800

Hi,

I think both methods are allowed. The two scenarios that they might be used are in Uniform and Tunnel model. In the Uniform model we probably like to copy the MPLS TTL to the IP TTL, and in Tunnel mode we probably like to just decrement the IP TTL by one.

Yours,
-Shahram

> -----Original Message-----
> From: francis arts vh624 8492 [mailto:[email-masked]]
> Sent: Monday, December 04, 2000 1:07 AM
> To: [email-masked]
> Cc: Francis Arts; Satoru Matsushima; [email-masked]; [email-masked]
> Subject: Re: Processing the MPLS TTL
> 
> 
> 
> Jim,
> 
> I agree that section 2.4.3 indeed indicates that "when a 
> label is popped, and the
> resulting label stack is empty, then the value of the IP TTL 
> field SHOULD BE
> replaced with the outgoing TTL value".
> 
> However, the last paragraph of section 2.4.3 also states that 
> 'it is recognized
> that there may be situations where a network administration 
> prefers to decrement
> the IPv4 TTL by one as it traverses an MPLS domain, instead 
> of decrementing the
> IPv4 TTL by the number of LSP hops within the domain."
> 
> So if one would use the latter approach, the TTL is not meant 
> to be copied from
> the MPLS header into the IP header in the LSP egress node.
> 
> Kind regards,
> 
>     Francis.
> 
> -------------
> 
> "James R. Leu" wrote:
> 
> > Section 2.4.3. "IP-dependent rules" of 
> draft-ietf-mpls-label-encaps-08.txt
> > contradicts what you're saying.  Did you get your info from 
> a different draft?
> >
> > Jim
> >
> > On Sat, Dec 02, 2000 at 11:27:23AM +0100, Francis Arts wrote:
> > >
> > > Hi Satoru,
> > >
> > > Please find included some information on the question you raised:
> > >
> > > > Could somebody tell me the behavior of "ingress|egress 
> LSR/LER" on
> > > >   this situations?
> > > >
> > >
> > > ** Ingress LSR:
> > > In this case the ingress LSR has to use for the MPLS 
> header a TTL that is
> > > large enough to reach the egress LSR (that is, the TTL 
> should not expire in
> > > the middle of the LSP).
> > >
> > > ** Egress LSR:
> > > At the egress LSR the TTL in the MPLS header is not 
> copied into the IP header
> > > of the packet. Instead the TTL as is in the IP header is used.
> > >
> > > This 'TTL behavior' is -for the TTL aspect- similar to 
> the 'TTL behavior' for
> > > IP over IP tunnels as defined in section 3.1 of RFC 2003 
> ('IP within IP').
> > >
> > > Kind regards,
> > >
> > >     Francis.
> > >
> > > --------------
> > >
> > >         ********************
> > >         *Extract from RFC 2003*
> > >         ********************
> > >
> > > 3.1. IP Header Fields and Handling
> > >
> > >    The fields in the outer IP header are set by the 
> encapsulator as
> > >    follows:
> > >
> > >       ....
> > >
> > >       Time to Live
> > >
> > >          The Time To Live (TTL) field in the outer IP 
> header is set to a
> > >          value appropriate for delivery of the 
> encapsulated datagram to
> > >          the tunnel exit point.
> > >
> > >     ...
> > >
> > >    When encapsulating a datagram, the TTL in the inner IP 
> header is
> > >    decremented by one if the tunneling is being done as part of
> > >    forwarding the datagram; otherwise, the inner header TTL is not
> > >    changed during encapsulation.  If the resulting TTL in 
> the inner IP
> > >    header is 0, the datagram is discarded and an ICMP 
> Time Exceeded
> > >    message SHOULD be returned to the sender.  An 
> encapsulator MUST NOT
> > >    encapsulate a datagram with TTL = 0.
> > >
> > >    The TTL in the inner IP header is not changed when 
> decapsulating.
> > >    If, after decapsulation, the inner datagram has TTL = 0, the
> > >    decapsulator MUST discard the datagram.  If, after 
> decapsulation, the
> > >    decapsulator forwards the datagram to one of its 
> network interfaces,
> > >    it will decrement the TTL as a result of doing normal 
> IP forwarding.
> > >    See also Section 4.4.
> > >
> > >     ...
> > >
> > > --------------
> > >
> > > Satoru Matsushima schreef:
> > >
> > > > Hi all,
> > > >
> > > > According to draft-ietf-mpls-label-encaps-08.txt,
> > > >
> > > > > 2.4.3. IP-dependent rules
> > > >
> > > > >   We define the "IP TTL" field to be the value of the 
> IPv4 TTL field,
> > > > >   or the value of the IPv6 Hop Limit field, whichever 
> is applicable.
> > > > >
> > > > >   When an IP packet is first labeled, the TTL field 
> of the label stack
> > > > >   entry MUST BE set to the value of the IP TTL field. 
>  (If the IP TTL
> > > > >   field needs to be decremented, as part of the IP 
> processing, it is
> > > > >   assumed that this has already been done.)
> > > > >
> > > > >   When a label is popped, and the resulting label 
> stack is empty, then
> > > > >   the value of the IP TTL field SHOULD BE replaced 
> with the outgoing
> > > > >   TTL value, as defined above.  In IPv4 this also 
> requires modification
> > > > >   of the IP header checksum.
> > > >
> > > > but this section had continue following.
> > > >
> > > > >   It is recognized that there may be situations where 
> a network
> > > > >   administration prefers to decrement the IPv4 TTL by 
> one as it
> > > > >   traverses an MPLS domain, instead of decrementing 
> the IPv4 TTL by the
> > > > >   number of LSP hops within the domain.
> > > >
> > > > I think that is very useful for VPNs, but this section 
> had not consider
> > > > this situations.
> > > >
> > > > Could somebody tell me the behavior of "ingress|egress 
> LSR/LER" on
> > > > this situations?
> > > >
> > > > Thanks in advance.
> > > >
> > > > --
> > > > Satoru Matsushima
> >
> > --
> > James R. Leu
>

---

From: "James R. Leu" <[email-masked]>
Date: Mon, 4 Dec 2000 08:48:45 -0600

Hello,

On Mon, Dec 04, 2000 at 04:59:35AM -0800, Shahram Davari wrote:
> Hi,
> 
> I think both methods are allowed. The two scenarios that they might be used
> are in Uniform and Tunnel model. In the Uniform model we probably like to
> copy the MPLS TTL to the IP TTL, and in Tunnel mode we probably like to just
> decrement the IP TTL by one.

Isn't there a possible interoperabilty problem with this?  The Ingress and
Egress have to agree on the same way of handling the TTL? AFAIK none
of the signling protocols convery this info.

Jim

-- 
James R. Leu