The MPLS WG Archive

["Krishnan, Vijay G." <Vijay.G.Krishnan@marconi.com>]

Hi,

I understand that the RSVP-TE finds the path MTU of an LSP based on the
minimum MTU size of the router interfaces on the path. The source (ingress
LSR or LER) can send the packets with this size to avoid fragmentation. Can
the packet size overshoot the path MTU due to addition of labels
(hierarchical tunnels or something) on its path, which might require
fragmentation? 

Will the LSP setup by RSVP-TE always have a stack depth of one label? or 
Is there a support to find out the max stack depth of an LSP?

It might be a bad network design to have both hierarchical tunnels and a low
MTU value in the core, but I was just curious...

thanks in advance 
Vijay



-----Original Message-----
From: Serge Maskalik [mailto:serge@ivmg.net]
Sent: Tuesday, December 12, 2000 8:01 PM
To: Steve Elias
Cc: mpls@UU.NET
Subject: Re: MPLS and fragmentation...


  Comments in-line.

Thus spake Steve Elias (eli@cisco.com):

> 
> hi Ben,
> 
> no i am not saying that.
> 
> to the contrary, i can imagine that an MTU communication mechanism in
> LDP could solve MTU-related problems inside an MPLS cloud, thus
> avoiding fragmentation within the cloud.  such a mechanism could
> operate just as well in an MPLS cloud with some nodes' interfaces
> configured to exceed the 'original' MTU standards.

   From the TE perspective, the LSPs are introduced into the IGP as 
  shortcuts or virtual links. If the ingress LSR is made aware of 
  the tunnel MTU, which would be exactly the smallest link MTU in
  the path, fragmentation can be done before traffic enters the 
  MPLS domain. IMO, fragmentation is significantly more complex
  when it is to be handled by a mid-point for the following reasons:

   1. LSR has no way to know what network layer protocol is 
      label-switched.

   2. Even if the LSR is aware of the underlying network layer
      protocol, what must it do? De-capsulate, fragment and 
      then encapsulate the fragments with identical label 
      headers? Does not sound like an efficient operation. 

   Existing mechanisms in RSVP-TE should be utilized for this 
  purpose. I would like to see feedback from authors of CR-LDP 
  in w/r/t to this. 

> 
> i'm not aware of any such fragmentation problems in real world MPLS
> clouds yet, but it seems reasonable to me to expect that sooner or
> later this issue would become important for some MPLS customers.

    A good example of such problem could be witnessed in many SP 
  architectures that use ethernet switch fabrics to make all core 
  and edge devices adjacent within a PoP. Various switch vendors 
  are not on the same page as far what is the max frame size they
  support, example - one platform does not support anything larger 
  than 802.3 header which may include 802.1q tag (in this case, 
  no label encapsulation is possible), another platform support
  frames up to 9k in size, but the forwarding is done via slow-
  path; third example is vendor which has an asic limitiation 
  which forces the max frame size of 1536 (which allows for a 
  stack three deep after subtracting 802.3 header). 

   Targeted MPLS deployments in SP networks that have provide for
  RFC2547 and L2 MPLS-based VPNs plus TE require support of label 
  stack of at least three labels (underlying RSVP-TE, LDP and VPN 
  labels). Other architecture may have a need for a deeper stack.  

	- Serge   
  
> 
> thank you,
> 
> steve elias
> 
> 
> 
> ben@layer8.net (Ben Black) writes:
> > are you saying that LDP need not include an MTU communication
> > mechanism because, on rare occassions, it is expedient to
> > violate accepted specifications?
> > 
> > 
> > ben
> > 
> > On Tue, Dec 12, 2000 at 09:15:03AM -0500, Steve Elias wrote:
> > > 
> > > hello,
> > > 
> > > indeed it is nice and is preferred that fragmentation occur outside
> > > the mpls domain.  but that's not always possible or reasonable in 
> > > real networks.
> > > 
> > > so within the mpls domain, and especially at the step where an ip
> > > packet is converted to mpls, it is quite possible and sometimes quite
> > > crucial to exceed the MTU.  for example, this is reasonable on
> > > ethernets on which there are only two (or a few) nodes present and for
> > > which the wire is not too close to the maximum length as determined by
> > > the medium's propagation speed and the collision-detect portion of the
> > > ethernet timing specification.
> > > 
> > > yes, this sort of thing violates a variety of standards.  
> > > but it solves customer problems.  
> > > 
> > > as long as the router does not default to being able to violate the
> > > MTU or an MPLS fragmentation specification, i say that it is a Good
> > > Thing for customers to be able to configure the router it to do so.
> > > 
> > > for example, in the simplest case, to send a 1504
> > > byte "baby giant" packet over a ethernet...
> > > 
> > > regards,
> > > 
> > > steve elias
> > > ios network protocols
> > > cisco systems
> > >