[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
Just to have disclosure for the current understanding
of this out on the list, the full proposal is given
below. LISP is used as the example RRG map-and-encaps
architecture, but the same approach can be applied to
any such scheme:
1) Add two flag bits plus an ID field to the LISP
header. The "Frag" flag is 0/1 if the packet is
unfragmented/fragmented, and the "Seg" flag is 0/1
if this packet is the A or B Segment of the original
packet. The ID field can be a 16-bit extension to
the IPv4 id, or a 32-bit ID that is independent of
the IPv4 id (FFS). To save encapsulation overhead,
the two flag bits could share the same word/longword
as the LISP ID field to give a 14+2 [ID/flags] field
or a 30+2 [ID/flags] field and still leave enough ID
bits to avoid reassembly misassociations.
2) Before the ITR knows whether the ITR->ETR tunnel
pathMTU can handle original packets up to 1500 bytes,
it sends 1500- original packets into the tunnel as
either 1-fragment or 2-fragment packets of no more
than (750+ENCAPS) bytes each. The assumption is that
packets of this size will NEVER be dropped due to an
MTU restriction in the ITR->ETR tunnel, which may
have implications for the placement of the ITR and
ETR in the network. (To the best of my knowledge,
the 750 byte fragment suggestion is attributed to
Iljitsch van Beijnum, however RFC1812 does suggest
that sending equal-sized fragments is a legitimate
fragmentation strategy.)
3) The ITR creates 2-fragment packets by splitting
the original packet into A and B segments. Both
segments set the "Frag" flag. The A segment sets
"Seg=0" and the B segment sets "Seg=1". Both segments
set corresponding values in the LISP ID field. (The
A and B segments should set different values in the
IPv4 ID, since the two packets might otherwise appear
as duplicates.)
4) While sending 2-fragment packets, the ITR sends
1500 byte sprite-mtu probes to the ETR. If it gets
probe replies back, it can stop sending 2-fragment
packets and begin sending 1-fragment packets. If the
ITR subsequently gets a packet-too-big, it can resume
sending 2-fragment packets and try probing again later.
5) The ITR admits 1501+ packets into the tunnel without
fragmenting them. FFS, the ITR either admits the packets
(if they are no larger than the outgoing IPv4 interface)
and sends NO PTB feedback back to the original source
(stateless), or admits the packet and also sends back a
PTB. In the latter case, the ITR also sends sprite-mtu
probes to determine the maximum packet size that the
ITR->ETR path can accommodate. When a maximum size is
determined, the ITR then has an accurate path MTU value
that it can use to determine when to send a PTB back to
the original source. But, this requires extra state in
the ITR. In both cases, the assumption is that original
sources that send 1501+ packets are also doing something
like RFC4821. This should appear in a BCP document.
6) The ETR must reassemble any 2-fragment packets. It
does so through simple concatenation of the A and B
parts of the 2-fragment packet. The ETR can greatly
reduce the memory required for reassembly buffers by
actively discarding any reassemblies that appear to
have no chance of completion. This assumes that any
packet reordering on the ITR->ETR path will be on the
order of a small number of positions (~100 or less),
and that any gross reordering will be short-lived
in nature. (In fact, if the ETR does this it might
be possible to drop back to using plain-old IPv4
fragmentation and reassembly instead of adding new
encapsulation overhead to LISP. But then, there would
still only be a 16-bit IPv4 ip_id which some have
argued is a problem. This is FFS.) In both cases,
the ETR must configure a reassembly buffer size of
at least 2KB to accommodate reassembly for 1500-
original packets plus any outer layers of encapsulation
including the LISP/UDP/IPv4 encapsulation and any
additional encapsulations such as IPsec/ESP, L2TP,
etc. To the best of my knowledge, the 2KB reassembly
requirement idea is attributed to a list posting from
Dan Romascanu (however I had heard it mentioned at
least once previously in private conversation) and
should also appear in a BCP document.
7) The idea of a 2-fragment maximum for fragmentation
is something that many of us have talked about over
the years in on- and off-list discussions and has also
appeared in some drafts. I believe Robin Whittle has
more recently been talking about this idea with specific
reference to the RRG problem space, but the idea itself
is not new.
8) Again, the above can apply equally to *any*
map-and-encaps tunnel-oriented proposal for RRG,
and not just LISP.
Fred
fred.l.templin@boeing.com
PS: If I have mis-attributed any of the ideas, or failed
to attribute others, please let me know. I recognize
that it can be very difficult to keep track of who
thought of what first...
> -----Original Message-----
> From: Templin, Fred L
> Sent: Tuesday, December 18, 2007 2:25 PM
> To: Routing Research Group list
> Subject: [RRG] LISP Fragmentation and Reassembly
>
> "sprite-mtu" identifies conditions under which the ITR
> must fragment outer packets which the ETR must reassemble.
> (And, from the list discussions, we seem to be reaching
> consensus that any reassembly at the ETR must be limited
> to 1500 byte or smaller original packets.) But, sprite-mtu
> further defines a "dance" that needs to be orchestrated
> between the ITR and ETR when IPv4 fragmentation and
> reassembly are occurring, which may be too onerous for
> some deployments.
>
> The reason for the dance is that the 16-bit ip_id needs
> to be carefully monitored when IPv4 fragmentation is
> occurring such that any reassembly misassociations are
> detected. But, if we disable IPv4 fragmentation and instead
> define a LISP-specific fragmentation and reassembly at
> the LISP shim layer immediately above UDP, then we can
> have the shim layer insert a 32-bit id which would avoid
> the RFC4963 issues and eliminate the need for close
> coordination with the ETR.
>
> I have already specified such a mechanism for DHCP:
>
> http://www.ietf.org/internet-drafts/draft-templin-dhcpmtu-00.txt
>
> and a similar specification for LISP would be nearly identical.
> The penalty is extra LISP encapsulation overhead, but the
> benefit of avoiding the need for synchronization between the
> ITR and ETR is substantial. (In fact, it may be essential to
> the successful deployment of LISP.) Also, when the path MTU is
> large enough to accommodate all 1500 byte and smaller packets
> without fragmentation, the extra encapsulation overhead can
> be eliminated.
>
> So, I am inclined to write this up as a draft but probably
> won't be able to get to it until after the 1st of the year.
> It could either go as part of the sprite-mtu draft, or as
> an independent draft like the DHCP one. But better yet
> would probably be to just put it directly into the LISP
> specification itself. What does anyone think?
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg