Subject: IP Fragmentation before entering LSP

From: Vishal Mishra <[email-masked]>
Date: Fri, 1 Jun 2001 22:06:35 -0700 (PDT)

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/

---

From: "Jay Wang" <[email-masked]>
Date: Mon, 4 Jun 2001 09:19:26 -0700

I think all the fragments should be applied with the same
classification policy. The identification field in the IP 
header would allow you to associate a fragment to a datagram 
at the LER.  In case a fragment arrives out of order before 
the first one comes, I think you may buffer it until the 
first one arrives or a timer expires. 

- jay

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Vishal
Mishra
Sent: Friday, June 01, 2001 10:07 PM
To: [email-masked]
Subject: IP Fragmentation before entering LSP

Hi Folks,

    Thanks for any help !!

Vishal.

---

From: David Charlap <[email-masked]>
Date: Mon, 04 Jun 2001 12:43:31 -0400

>     This would lead to a whole lot of problems (including out of

If the ingress LER is going to classify on L4+ information, then that
information must obviously be present.  There are only three possible
choices I can see here:

1: Have the ingress LER reassemble the fragments before injecting
   into the LSP (possibly re-fragmenting them after reassembly).
   The upside is that it eliminates this problem altogether.  The
   downside is that it may be impossible to do this at line-rate,
   and the router will have to deal the the possibility that some of
   the fragments may never arrive (perhaps they got routed through
   some other router, or perhaps they were lost.)

2: Have the ingress LER forward the first fragment (the one with the
   L4 header) according to its policy, and ignore the L4 information
   for other packets.  The upside is that you don't have to worry
   about late/missing fragments.  The downside is that the first
   fragment may take a different route through the network from the
   other fragments, leading to out of order delivery.

3: Have the ingress LER use stateful packet inspection.  When the
   first fragment arrives, it should record enough information to be
   able to recognize the remaining fragments and send them into the
   same LSP.  The upside is that it solves the problem and you don't
   need to buffer the entire packet.  The downside is that the first
   fragment may not arrive first, and that you need to deal with the
   possibility that one or more fragments may never arrive.

The only way to avoid the problem altogether is to restrict your packet
classification to what is available in the IP header.  But this may not
be acceptible to all customers.

-- David

---

From: Eric Gray <[email-masked]>
Date: Mon, 04 Jun 2001 13:00:47 -0400

David,

    There's a fourth option implied in the downside of each of your
3 listed options.  Since it is possible for the packets to arrive out
of order at the ingress to the LSP, then it is also likely that it is
acceptable to just do as Vishal suggested (even though this seems
not to be a preferred option).  If it was possible for packets to arrive
out of order at the ingress, then it was certain that they would have
arrived out of order at the destination.  Why should we expect the
ingress LSR to fix this?

--
Eric Gray

---

From: Ron Bonica <[email-masked]>
Date: Mon, 04 Jun 2001 13:49:10 -0400

Dave,

As you have observed, options 1 and 3 may not be compatible with line rate
forwarding in the network core. Option 2 may cause fragment re-ordering.

A fourth option is to prevent all fragments from traveling on an LSP. If
possible, forward all fragments using standard IP forwarding mechanisms. If
this is not possible, discard the datagram.

                                     Ron

> From: [email-masked] [mailto:[email-masked]]On Behalf Of David
> Charlap
> Sent: Monday, June 04, 2001 12:44 PM
> To: [email-masked]
> Subject: Re: IP Fragmentation before entering LSP
>
>
> Vishal Mishra wrote:
> >

---

From: "Jay Wang" <[email-masked]>
Date: Mon, 4 Jun 2001 11:15:38 -0700

I agree with most but I think applying one policy to the first fragment 
and another to the rest is problematic, particularly from the QoS's 
perspective, if not for others. So although all possible, I think options 
1 and 3 are more realistic. But between 1 and 3, I think if you can do 1, 
you have done 3 already. You need to deal with out-of-order arrivals
or fragments that never come for both options 1 and 3, but 3 is
almost like a subset of 1, operation wise. One problem with
option one is that the packets arrive in fragments most likely is
because of the MTU restriction in the first place. If you physically 
reassemble the fragments, the lower layer has to break them up again 
on the way out, most likely.  Yet another thing is, if you physically 
reassemble them, your switch/router has to deal with jumbo frames, 
not necessarily hardware friendly thing to have. I think 3 is probably 
better. Once the first fragment arrives, you know what to do for the
rest and you don't have to hold on to them. Implementation wise, as 
also indicated in my previous message, I think it should be fairly
straightforward and not too expensive either.

- jay 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David
Charlap
Sent: Monday, June 04, 2001 9:44 AM
To: [email-masked]
Subject: Re: IP Fragmentation before entering LSP

-- David

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Tue, 5 Jun 2001 14:53:58 +0530 (IST)

Hi!
	Can anyone tell me what is this concern about fragment
re-ordering ?? IP fragmentation/reassembly is immune to fragment
re-ordering, then why is this concern in the last few mails in this
thread. I can understand the other concerns shown in this thread.

regards
tomar

-- 

------------------------------------------------------------------------------
 Nagendra Singh Tomar
 
 Residence:
 369 KHB Colony
 5th Block Koramangala
 Bangalore 95
 INDIA
 Phone : 5524839
 email : [email-masked]

"Sometimes quantity becomes quality"                                          
                            --Gary Kasparov,                                  
 When he played against Deep Blue. He said this after looking at a           
 computer which found a forced mate in 249 in an endgame, after calculating   
 all the possible moves with only 5 pieces left on the board.                 
------------------------------------------------------------------------------