The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Apr> msg00466



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

Fragmentation in RFC-3032

  • From: Eric Gray <eric.gray@sandburst.com>
  • Date: Wed, 25 Apr 2001 14:34:06 -0400
  • Cc: "'mpls@uu.net'" <mpls@UU.NET>

David,

    Correct me if I'm wrong (or feel free to correct me if
I'm right ... again), but ATM switches switching ATM
cells have no way to know if an IP packet that extends
over multiple cells is "too long".

    I believe this determination would be made by that
ATM switch saddled with SAR responsibility.  If that is
the case, why would that ATM switch be intrinsically in-
capable of fragmenting IP packets?

--
Eric Gray

You wrote:

> Eric Gray wrote:
> >
> > In addition to what Jack says below, the intent is to specifically
> > allow implementations to silently discard packets it might otherwise
> > be expected to fragment.
>
> More specifically, some hardware (especially legacy ATM hardware) may be
> incapable of performing IP fragmentation.  These same boxes may also be
> incapable of generating ICMP messages.
>
> If a too-large packet arrives at such a box, it has no choice but to
> drop it.
>
> Ideally, the LER that admits the packet into the LSP should check the
> size and fragment (or generate ICMP if DF is set) to the LSP's MTU size
> (that is, the mimimum MTU of all the routers along the LSP).  But this
> may not always be possible - not all signaling protocols report the
> LSP's MTU to the ingress router.
>
> Hence the RFC, which allows LSRs to either fragment or discard too-large
> packets that don't have DF set.
>
> -- David