Re: New Internet Draft on automatic (end-user) tunneling for SSM

[Tom Pusateri <pusateri@juniper.net>]

In message <4.3.1.1.20010224023311.00b3e400@localhost> you write:
>At 02:07 AM 2/24/01, Dino Farinacci wrote:
>> >>  From my understanding of GRE (please correct me if I'm wrong), the
>> >> overhead to tunnel an arbitrary UDP multicast packet using GRE would 
>> be 32
>> >> bytes: 4 bytes (for the GRE header), plus 28 bytes (for the UDP/IP 
>> headers
>> >> of the encapsulated packet).
>>
>>     The overhead is an additional 24 bytes (20-byte fixed IP header and 
>> 4-byte
>>     GRE header).
>
>But what about the UDP header of the packet that's being tunneled (i.e., 
>the inner packet)?  That's another 8 bytes.  Wouldn't that go in the GRE 
>packet as well?
>
>         Ross.

I'm confused and possibly others are as well. The word encapsulate
has a very specific meaning while the word tunnel does not.

Encapuslate means "to enclose" which, when dicussing packets, should
be interpreted to mean to add octets in front of, or add
octets at the end, or both.

But tunneling can be done in many ways including encapsulation,
rewriting headers, adding source route options, etc.

So when talking about overhead, please be more clear about exactly
type of tunneling is going on.

Ross suggested that UMTP's trailer is to allow normal RTP header
compression. Looking at the UMTP spec, it is difficult to determine
if the original IP headers are rewritten or not. I assume so
since it looks like the old IP header info is stored in the trailer.
This should not be called encapsulation if the headers are
modified before the trailer is added, or at least the
word rewrite should be used in conjunction with the word
encapsulate. This is tunneling though.

Dino's GRE mechanism is simply adding a new IP header and GRE
header in front of the original IP header without modifying the
original IP datagram. This is a true encapsulation. This is also
a form of tunneling.

A major advantage to encapsulation over option insertion or IP
header rewriting is that routers already do this in existing
hardware. Other tunneling mechanisms that use header rewriting or
option insertion are more difficult or impossible to do in hardware
causing them to be shifted to valuable general purpose CPUs. Some
routing vendors will refuse to implement these schemes.

I would request that Ross clarify draft-finlayson-umtp-05.txt
about the use of encapsulation and header rewriting.

GRE adds: 24 bytes (20 byte IP + 4 byte GRE header)
IPIP adds: 20 bytes (20 byte IP)

If UMTP rewrites the original header plus adds the trailer,
it adds just the trailer which is 12 or 16 bytes.

If UMTP encapsulates the original packet with IP and UDP and adds the trailer,
it adds: 48 (20 byte IP + 8 byte UDP + 16 byte trailer)

If UMTP strips the IP header, adds a new UDP header and a trailer, its adds
24 (8 + 16 byte trailer).

A clarification on this would be great.

Of all of these options, GRE or IPIP are simplest to implement in hardware
which will give you the performance and scaling needed for large rollouts.

Thanks,
Tom