Subject: RE: IP Fragmentation before entering LSP

From: Vishal Mishra <[email-masked]>
Date: Tue, 5 Jun 2001 21:07:52 -0700 (PDT)

IP fragmentation would not be a problem for stream based protocols.

Looking at the fact that the bulk of Internet Traffic, esp. the
connection oriented traffic is TCP based, which does Path MTU 
Discovery, most of the LSPs would carry complete IP packets, since
IP packets holding TCP data would never need to be fragmented.

For protocols that use UDP or other/raw IP packets, some can be
classified under the category - 
(1) They can break a large protocol PDU into multiple small PDUs, 
and
(2) Those that require complete Protocol PDU to go in a single IP 
packet.
(Not quite the best Example: Assuming that RSVP and OSPF packets 
 want to ride through LSP tunnels for some reason - 
 RSVP can choose to break a large RSVP packet holding a Bundle 
 Message, into multiple small single/bundle messages, but
 OSPF cannot break a packet holding a large number of Router
 LSAs into multiple packets, even if it 'knew' the Path MTU)

By-Passing the Problem -
The category-1 protocol implementations can simply introduce the
Path MTU Discovery mechanism to by-pass the fragmentation problem
(MPLS aware version of daemon !!).
 
The category-2 protocols would not be able to get the benefit of the
LSP (only for L4+ based LSP), whenever the are forced to send large 
IP Packets.

Vishal.

--- Eric Gray <[email-masked]> wrote:
> Nagendra,
> 
>     Vishal's original question had to do with a general concern that
> already
> fragmented UDP packets might arrive at a point where a TE LSP
> originates.
> If the basis for ingress to the TE LSP is a specific L4 attribute, it
> is possible
> that the first IP fragment will qualify for ingress and the rest will
> not.  While
> out of order delivery is a concern in this situation, perhaps a more
> important
> concern is that the 'service' associated with the TE LSP was meant to
> apply
> to the entire UDP packet.  Since all but the first fragment do not
> receive this
> 'service' (whatever it is), the entire packet is at least as bad off
> as if no part
> of it received the 'service'.
> 
>     The issue with re-ordering IP fragments is that many stack
> implementations
> do this somewhat sub-optimally.  Thus, if fragments are re-ordered,
> this could
> lead to further degradation of the 'service' intended for this
> packet.
> 
>     An example of a 'service' degradation might be the case where a
> certain class
> of UDP packets are intended to be filtered (possibly to prevent
> certain types of
> denial of service attack).  In this case, filtering the first
> fragment could result
> in
> a greater 'denial of service' impact that if the filtering service
> did not exist.
> 
>     I think Dave Charlap and Ron Bonica were going in the right
> direction with
> their
> suggestions.  It seems to me that the LSR at the ingress needs to be
> more aware of
> its limitations.  If it is not able to ensure that all subsequent IP
> fragments will
> go
> on the same LSP, it should not admit the first one.  Either it uses
> Dave's options
> 1 or 3, it forwards using IP or it drops the packet (as Ron
> suggested).  Note that
> this is also consistent with Jay's initial suggestion to employ the
> same policy to
> all IP fragments.
> 
> --
> Eric Gray
<snipped>
>> Hi Folks,
>>
>>    How are fragmented IP Packets identified by the Ingress LER
>> if the basis of classification involves part of the IP Payload, 
>> such as the Transport Layer address (say UDP Port) ?
>>
>>    Does this mean only the first fragment of all such IP Packets
>> travel through the Traffic Engineered LSP, and the rest of the IP
>> fragments (being unclassified) follow the best effort (Non-TEed)
>> Path ?
>>
>>    This would lead to a whole lot of problems (including out of
>> order packets).
>>
>>    Thanks for any help !!
>>
>> Vishal.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/