From: Jason1 (jason1@xxxxxxxxxx)
Date: Wed Feb 07 2001 - 13:15:16 GMT-3
My assumation has been that the router doesn't have to wait for all the
original fragments to arrive , reassemble and refragment. Rather it work on
the existing fragments to further fragment it for the new MTU if the new MTU
is smaller, all reassembly should be at the final destination.
----- Original Message -----
From: "Priscilla Oppenheimer" <cilla@priscilla.com>
To: "Chuck Larrieu" <chuck@cl.cncdsl.com>; "Choon, Raymond ()"
<rchoon@att.com>; "'Tariq Sharif'" <tariq_sharif@btinternet.com>;
"Ccielab@Groupstudy. Com" <ccielab@groupstudy.com>
Sent: Wednesday, February 07, 2001 8:41 AM
Subject: RE: Fragmentation Concepts
> What list did this come from and how do I join?
>
> Usually when a host or router fragments an IP datagram, it is not
> reassembled until it reaches the final destination. Each fragment has the
> same ID in the IP header. The offset field in the header allows the
> recipient to put the fragments back in order for delivery to the next
layer up.
>
> What you are talking about in this devious example is fragmentation of
> fragments. In that case, I think the router would have to wait for all the
> original fragments to arrive, reassemble them, and refragment them for the
> new MTU. Obviously this should be avoided if at all possible.
>
> Applications can do an MTU discovery by sending varying sized frames with
> the Don't Fragment bit set until a good frame size is found.
>
> Priscilla
>
> At 03:56 PM 2/6/01, Chuck Larrieu wrote:
> >Original question:
> >
> >Host A sends 1500 bytes long packet to e0 of R1 (destined for Host B).
> >R1 s0 has MTU set to 750 bytes. So R1 fragments packet into 2.
> >R2 has MTU of 375 bytes on s1, R2 fragments packet into 2
> >R3 has MTU of 1500 on Ethernet LAN B, so it reassembles the fragments
into
> >one 1500 byte long packet & hands it to Host B??
> >
> >Long winded response:
> >
> >Another way to look at this is in terms of protocol behaviour at the
various
> >layers.
> >
> >Application / layer 7 is the interface between the rest of the protocol
> >stack and the user application
> >
> >TCP / layer 4 is responsible for reliable end to end reliable transfer of
> >data.
> >
> >IP / layer 3 is responsible for path determination and packet forwarding
> >
> >Frame/ layer 2 is where the physical limitations of packet size occur.
E.g.
> >token ring MTU versus ethernet MTU
> >
> >If a router receives a valid packet, and has a route to the destination
> >contained within that packet, there is nothing for the router ( layer 3
> >device ) to do other than to forward it.
> >
> >In terms of the following model:
> >
>
>Host_1----segment_1----Router_1------segment_2------Router_2----segment_3--
-
> >------Host_2
> >
> >( I'm going to assume that the OSI model doesn't exactly fit here in the
> >real world of computer processor operations, and that in terms of actual
> >stack operation, there is interaction up and down )
> >
> >Layer 7 - app sends 2 meg file to host_2
> >Layer 4 - TCP prepares the TCP packet, based on what it knows of the
> >transmission requirements, including MTU
> >Layer 3 - IP interacts with layer 2 data link - to get the proper size
frame
> >to the next point in the path
> >Layer 3 - IP - router receives packet, forwards it. If the outbound
> >interface segment requires a smaller packet size, ip fragments it.
> >Layer 2 - data link - rules of the data link segments determine MTU
> >
> >Segment 1 is a token ring with an MTU of 4480, segment 2 is an ethernet
> >with an MTU 1500, and segment 3 is another token ring, with an MTU of
> >17000.
> >
> >Host 1 is sending a 2 meg file to host 2. TCP breaks that file into
smaller
> >chunks, based on the segment MTU. IP fragments further based on segment
MTU
> >at the next lower level. The data itself, i.e. the 2 meg file, is of use
to
> >host 2 only as a single file. The protocol stack on host 2 is responsible
> >for receiving and checking the data, based on information handed up from
the
> >lower layers.
> >
> >It would be highly inefficient for the routers along the path to have to
> >examine each packet with the purpose of determining if the packets had
been
> >fragmented and could be consolidated, not to mention the nature of the
> >fragmentation. Layer 3 devices just send packets on their merry way
without
> >any concern as to whether or not there are better ways to do this.
> >
> >Hhmmmm.... This could be better written. To bad Priscilla Oppenheimer
isn't
> >on this list. This deserves a good writer :->
> >
> >Chuck
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> >Choon, Raymond ()
> >Sent: Tuesday, February 06, 2001 10:23 AM
> >To: 'Tariq Sharif'; Ccielab@Groupstudy. Com
> >Subject: RE: Fragmentation Concepts
> >
> >Routers don't reassemble packets. Host B receives packets with MTU of
375
> >bytes and host B will reassemble packets to 1500 bytes because this is
the
> >original MTU from host A.
> >
> >I do not have any references for that. This is from my memory when I ran
> >into doing troubleshooting before. Correct me if I'm wrong.
> >
> >Raymond Choon
> >
> >-----Original Message-----
> >From: Tariq Sharif [mailto:tariq_sharif@btinternet.com]
> >Sent: Tuesday, February 06, 2001 1:01 PM
> >To: Ccielab@Groupstudy. Com
> >Subject: Fragmentation Concepts
> >
> >
> >Need some help on understanding IP fragmentation. In the setup below, are
> >the steps below correct?
> >
> >
> >LAN A |
> > |
> >Host A_| Serial line 1 Serial line 2
> >| LAN B
> > |______e0 R1 s0-------------------s0 R2
> >s1---------------------------s0 R3 e0 -----------|
> > |
> >|
> > |
> >|-------Host B
> >
> >Host A sends 1500 bytes long packet to e0 of R1 (destined for Host B).
> >R1 s0 has MTU set to 750 bytes. So R1 fragments packet into 2.
> >R2 has MTU of 375 bytes on s1, R2 fragments packet into 2
> >R3 has MTU of 1500 on Ethernet LAN B, so it reassembles the fragments
into
> >one 1500 byte long packet & hands it to Host B??
> >
> >Any references to sites/books will be greatly appreciated.
> >
> >Many thanks & regards.
> >
> >Tariq Sharif
> >
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:40 GMT-3