[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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