[RRG] Alternative to encapsulation: IPv4 ETR Address Forwarding (EAF)

[Robin Whittle <rw@firstpr.com.au>]

I have a new I-D:

http://www.ietf.org/internet-drafts/draft-whittle-ivip4-etr-addr-forw-01.txt
http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01

The idea is very simple, and the I-D describes it and its
implications fully.  A brief description of EAF is:

   The ITR sets bit 48 of the IPv4 header to 1 and 30 other bits
   of the header (currently used for the More Fragments flag, the
   Fragment Offset field and the Header Checksum) are then used to
   carry the 30 most significant bits of the ETR's address.

   Routers (core BGP routers and potentially internal routers) with
   modified functionality recognise the EAF formatted header, and
   forward the packet to the ETR according to this address, rather
   than according to the destination address.

   The ETR converts the header back to its normal state and delivers
   the packet to the destination network.  Routers sending ICMP
   messages, such as Packet Too Big or other messages in response to
   traceroute, perform the similar conversion on the modified header
   to reconstruct the IPv4 version of the packet - so PMTUD works
   directly for all routers between the ITR and the ETR.

EAF has the following advantages over map-encap:

   1.  There is no transmission overhead - the packet is not made
       any longer.

   2.  Conventional RFC 1191 PMTUD is supported over the entire
       path, including between the ITR and ETR, without any
       involvement of the ITR.

   3.  Traceroute will work over the entire path.

Avoiding encapsulation overhead is a major long-term benefit,
especially for VoIP packets.

The retention of conventional RFC 1191 PMTUD through the ITR to ETR
path removes the need for a great deal of complexity which would
otherwise be required in map-encap ITRs and ETRs.

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/


The difficulty with EAF is that most or all core routers would need
to have a relatively minor change to their FIB functionality.  No
BGP changes are required.

EAF could be used as a second mode of operation for Ivip - to be
introduced initially with encapsulation, but in the long-term
transitioning to the simpler and 100% efficient EAF mode once
sufficient routers have the requisite functionality.

A better approach may well be possible:  By the time we figure out
what core-edge separation scheme to use for IPv4, we may find that
it would be easier to upgrade the routers then to spend the extra
time, effort and expense constructing ITRs and ETRs which can do
encapsulation - and all the complications which are required to make
PMTUD work with encapsulation.

In that case, the system would use EAF alone from the start - a much
simpler and more elegant approach than using encapsulation.

Even if the scheme started with encapsulation, since since EAF
functionality in ITRs and ETRs is so simple, it would make sense to
include it in every ITR and ETR, ready for the day when core and
internal routers are upgraded.


EAF wouldn't work for LISP or APT - since they require LISP or APT
headers for all data packets.  Those headers could be added, but
this would nullify the two big benefits of EAF over map-encap -
packets being no longer, and natural, direct, RFC 1191 PMTUD.

It may be applicable to TRRP, but only if the ETR doesn't need to
know the address of the ITR.  EAF - and Ivip's IP-in-IP map-encap
approach, does not convey to ETRs the address of the ITRs from which
packets are being are tunneled.

   - Robin            http://www.firstpr.com.au/ip/ivip/




--
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