Opened 10 years ago

Closed 10 years ago

#1 closed technical (no consensus)

Proposal for new Path MTU behavior

Reported by: Fred.L.Templin@… Owned by:
Priority: major Component: draft-ietf-lisp
Severity: - Keywords:
Cc:

Description (last modified by hartmans-ietf@…)

te - this I think being close
to the final. This version is more adept at handling
recursion, and also accounts for pesky routers that
cause the first fragment to be the smallest when doing
IPv4 fragmentation (albeit with some state required).

Fred
fred.l.templin@…

--- begin ---
5.4.1. MTU Handling

An ITR solution to handle MTU issues is described as follows:

  1. Define M to be the minimum of the MTU of the underlying

interface over which the ITR->ETR tunnel is configured and
the path MTU across the tunnel (if known).

  1. Define an architectural constant S for the maximum size of a

packet, in bytes, an ITR would receive from a source inside of
its site and admit into the tunnel without first performing
fragmentation (if the packet is allowed to be fragmented).

  1. Define L to be the maximum size, in bytes, a packet of size S

would be after the ITR prepends the LISP header, UDP header, and
outer network layer header of size H.

  1. Calculate: S + H = L.

This specification recommends that L be defined as 1500.

When an ITR receives a packet from a site-facing interface and adds H
bytes worth of encapsulation to yield a packet size that is larger
than L bytes, it resolves the MTU issue by first splitting the
original packet into fragments. The first fragment must be the
minimum of 1280 and (M - H) bytes, and the other fragments must be no
larger than the first fragment. A LISP header is then prepended to
each fragment. This will ensure that the new, encapsulated packets
are unlikely to be above the effective tunnel MTU.

When an ETR receives encapsulated IP fragments, it treats them as
individually encapsulated packets. It strips the LISP headers then
forwards each fragment to the destination host of the destination
site. The fragments are reassembled at the destination host into
the single IP datagram that was originated by the source host.

This behavior is performed by the ITR when the source host originates
a non-LISP packet with the DF field of the IP header set to 0, or a
LISP packet with the RF field of the LISP header set to 0. For all
other packets, the ITR will encapsulate the packet and admit it into
the tunnel if it is no larger than (M - H) bytes. Otherwise, it will
drop the packet and return a Too Big message (i.e., an ICMP Packet
Too Big message for non-LISP packets or a LISP Fragmentation Report
for LISP packets). The message must contain as much of the invoking
packet as possible without the entire message exceeding the minimum
MTU (i.e., 576 bytes for IPv4 and 1280 bytes for IPv6).

When the LISP encapsulation uses an IPv4 header the ITR sets the DF
bit to 0. If the original packet was itself a LISP packet, the ITR
sets the RF bit in the encapsulating LISP header to the same value
that was set in the original LISP header. If the DF bit of the IP
packet is set to 1, or if the packet is an IPv6 packet, the ITR
sets the RF bit in the encapsulating LISP header to 1. In all other
cases, the ITR sets the RF bit to 0.

After sending the packet, the ITR may receive a LISP Fragmentation
Report message. If the message contains enough of the packet-in-error
and a reasonable MTU value (i.e., one no smaller than 576 bytes for
IPv4 or 1280 bytes for IPv6), the ITR translates it into a Too Big
message and returns it to the original source. Otherwise, the ITR
uses a plateau table (e.g., as described in RFC1191) to cache a value
for M which it iteratively decreases based on subsequent Too Bigs
until no further Fragmentation Reports are received.

When an ETR receives a fragmented LISP packet (i.e., one where the
encapsulated packet experiences fragmentation on the path from the
ITR), it either reassembles or discards the packet according to its
configuration. If the RF bit is set to 1 in the outer LISP header,
the ETR also generates a Fragmentation Report message that it returns
to the ITR. The message must contain as much of the first-fragment as
possible without the entire message exceeding the minimum MTU (i.e.,
576 bytes for IPv4 and 1280 bytes for IPv6).

--- end ---

Change History (2)

comment:1 Changed 10 years ago by hartmans-ietf@…

  • Reporter changed from hartmans-ietf@… to Fred.L.Templin@…

I have come up with some slight adjustments wrt the LISP
path MTU procedures that I posted on 6/4/09. In particular,
I am no longer asking for a Report Fragmentation (RF) bit,
as each and every LISP packet will be used as an implicit
probe and the ETR will generate a Fragmentation Report if
any fragmentation occurred. Instead, I am asking for a 'D'
bit in the LISP header which is copied from the DF bit
in the inner IP packet.

I am also backing off on the claim that the ITR need not
maintain path MTU state in the general case. This needs
a bit more investigation, but it seems the most robust
approach might be to have the ITR cache the path MTU
and drop too-big packets instead of admitting them into
the tunnel.

Fred
fred.l.templin@…


From: Sam Hartman hartmans-ietf@…
Sent: Tuesday, June 09, 2009 6:33 AM
To: lisp@…
Subject: Re: [lisp] Path MTU concerns and proposed resolutions

[respond byJune 13]

Fred has made a proposal for changes to the LISP MTU handling
procedure. Presumably if the WG were to adopt these changes we'd need
to define an RF header bit and a fragmentation report message.

So far, no one besides Fred has indicated support for the proposal.
In order for the proposal to be adopted we'll need to reach a rough
consensus of the WG. The chairs request that anyone wishing to
express support for this proposal do so by June 12, 2009.
_
lisp mailing list
lisp@…
https://www.ietf.org/mailman/listinfo/lisp

comment:2 Changed 10 years ago by hartmans-ietf@…

  • Description modified (diff)
  • Resolution set to no consensus
  • Status changed from new to closed

The chairs requested indications of support by June 12. Besides
Fred's initial indication of support, no one else came forward
supporting this issue. As such, the chairs do not see the necessary
support to adopt these changes and this issue is closed.

Note: See TracTickets for help on using tickets.