Subject: [RRG] LISP Fragmentation and Reassembly

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Dec 2007 14:24:37 -0800

"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
[email-masked] 

--
to unsubscribe send a message to [email-masked] 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Dec 2007 14:42:01 -0800

> then we can have the shim layer insert a 32-bit id

On further thought, we can probably just insert a 16-bit
field in the LISP shim layer that serves as an extension
of the 16-bit ip_id field to make for a combined 32-bit
ID for LISP fragmentation and reassembly.

Fred