Hi,
A small note to add, the previous reply was in reference to the RFC 3032, section 3.2//
3.2. Maximum Initially Labeled IP Datagram Size
Every LSR which is capable of
a) receiving an unlabeled IP datagram,
b) adding a label stack to the datagram, and
c) forwarding the resulting labeled packet,
SHOULD support a configuration parameter known as the "Maximum
Initially Labeled IP Datagram Size", which can be set to a non-
negative value.
If this configuration parameter is set to zero, it has no effect.
If it is set to a positive value, it is used in the following way.
If:
a) an unlabeled IP datagram is received, and
b) that datagram does not have the DF bit set in its IP header,
and
c) that datagram needs to be labeled before being forwarded, and
d) the size of the datagram (before labeling) exceeds the value of
the parameter,
then
a) the datagram must be broken into fragments, each of whose size
is no greater than the value of the parameter, and
b) each fragment must be labeled and then forwarded.
For example, if this configuration parameter is set to a value of
1488, then any unlabeled IP datagram containing more than 1488 bytes
will be fragmented before being labeled. Each fragment will be
capable of being carried on a 1500-byte data link, without further
fragmentation, even if as many as three labels are pushed onto its
label stack.
In other words, setting this parameter to a non-zero value allows one
to eliminate all fragmentation of Previously Labeled IP Datagrams,
but it may cause some unnecessary fragmentation of Initially Labeled
IP Datagrams.
Note that the setting of this parameter does not affect the
processing of IP datagrams that have the DF bit set; hence the result
of Path MTU discovery is unaffected by the setting of this parameter.
HTH-Cheers,
Swaroop
