Subject: RE: MPLS and fragmentation...

From: "Krishnan, Vijay G." <[email-masked]>
Date: Wed, 13 Dec 2000 17:42:45 -0500

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:[email-masked]]
Sent: Tuesday, December 12, 2000 8:01 PM
To: Steve Elias
Cc: [email-masked]
Subject: Re: MPLS and fragmentation...

  Comments in-line.

Thus spake Steve Elias ([email-masked]):

> 
> 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
> 
> 
> 
> [email-masked] (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
> > >

---

From: Ben Black <[email-masked]>
Date: Wed, 13 Dec 2000 15:08:25 -0800

> (hierarchical tunnels or something) on its path, which might require

The MTU determined should take into account whatever the depth of the label
stack actually is for the given LSP.  Fragmentation is not avoided, it is
simply done, if required, outside the MPLS domain.

ben

---

From: David Fiore <[email-masked]>
Date: Wed, 13 Dec 2000 18:38:04 -0500

--On Wednesday, December 13, 2000 03:08:25 PM -0800 Ben Black 
<[email-masked]> wrote:

>> 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?
>>
>
> The MTU determined should take into account whatever the depth of the
> label stack actually is for the given LSP.  Fragmentation is not avoided,
> it is simply done, if required, outside the MPLS domain.

It would seem to me that fragmentation must occur inside of the MPLS domain 
becuase if it didn't, why would the LSR MIB we have the following object, 
instantiated on all MPLS interfaces:

mplsInterfaceOutFragments OBJECT-TYPE
   SYNTAX        Counter32
   MAX-ACCESS    read-only
   STATUS        current
   DESCRIPTION
       "This object counts the number of outgoing MPLS
        packets that required fragmentation before
        transmission on this interface. This object
        MUST count on a per-interface basis regardless of
        which label space the interface participates in."
::= { mplsInterfacePerfEntry 4 }

-dbf

------------------------------------------------------------------------
                 \\\|///
               \\  _ _  //
                (  @ @  )
+-------------oOQo-(_)-oQOo----------+
|  +----------+                      |
|  | __    __ | David Fiore          |
|  | | \  / | | Staff Engineer       |
|  | |  \/  | | Micromuse Corp.      |
|  | | |\/| | |                      |
|  | | |  | | | 914.747.7630 (o)     |
|  | +-+  +-+ |                      |
|  +----------+ [email-masked]  |
+----------------------Oooo----------+
               oooO   (   )
              (   )    ) /
               \ (    (_/
                \_)

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Dec 2000 13:46:36 -0500

Ben,

    The number of labels required to forward packets on
a particular interface is a factor in determining the max
MTU size for that interface.  If the "interface" is an LSP
(or possibly stacked LSPs), then the LSR should take
additional labels into account in determining the maximum
MTU size.  Note that this does not mean that the LSR
needs to know how many labels may be put on the packet
as it is forwarded by other LSRs.  It only need to know
the intrinsic maximum frame size for the LSP it will be using
and the number of labels that it will put on.

    If there is a downstream LSR that adds additional labels
but has a larger maximum frame size, then the frame size
for the local LSR is unaffected by this.  It is generally best
not to know more than you need to.

--
Eric Gray

---

From: Ben Black <[email-masked]>
Date: Thu, 14 Dec 2000 10:36:17 -0800

> not to know more than you need to.

This is exactly what I said.  The MTU determined should take into account
the additional labels.  I am not promoting a specific mechanism for
determining the MTU.  If the edge media MTUs are smaller than the core
media MTUs by enough to account for the labels, then the labels are
accounted for.  I am not clear on what you are arguing.

ben