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

[Ross Finlayson <finlayson@live.com>]

Dino, thanks for the comments.

>    o Indicate the packet format encoding for join and prune messages.

The packet format for these packets is UMTP, which is defined in a separate 
Internet Draft <draft-finlayson-umtp-05.txt>.  The tunneling draft makes 
this clear, I hope!  (In reality, the actual tunneling protocol that ends 
up getting used might end up being a 'UMTP-light', as the current UMTP was 
designed for arbitrary multicast (SSM or ISM) tunneling between arbitrary 
end nodes - and so is (arguably) a little heavier-weight than needed here.)

>    o Be very clear that the Router-Alert option is used for control packets
>       from master to slave.

No go.  The scheme *has* to be usable by existing users, without operating 
system changes (e.g., the millions of people running Windoze 9x) - 
otherwise it's of little value, IMHO.  The control packets sent by end-user 
machines need to be regular UDP packets.  Routers will need to trap these 
control packets based upon their destination UDP port; they can't rely on 
the "Router-Alert" option.

>    o Indicate that data packets from the slave to the master do not need to
>       be UDP checksummed.

OK, fair enough.

>    o Be more clear about "data packets from the master are processed like
>       any other multicast packet in the router". This is certaily not true.

Yes, that's not true - and in fact I don't say this anywhere.  I think you 
may have misread the last paragraph of section 4.

>    o Indicate how TTL and TOS header bits are handled. That is, is the UDP
>       tunnel 1-hop or more.

Potentially many-hop.  Remember, the end-user (master) application just 
sends out regular UDP packets, addressed to the SSM 
source.  Non-multicast-capable routers forward these as many times as 
necessary, until a multicast/tunneling-capable router is reached.

>    o What is the source IP address of the UDP encapsulated packet forwarded
>       by the encapsulating router.

The draft currently doesn't say anything about this.  UMTP, as currently 
defined, uses source IP addresses for authentication, in which case the 
router would need to set the source IP address of the tunneled DATA packet 
to the SSM source.  But if it would be better for the router to use its own 
IP address instead, then that's something that could be changed...

>     o And as always with tunnels. How do you propose to deal with MTU issues
>       since an additional 28 bytes are added to the data packet.

For now at least, I don't propose doing anything about this.  If 
fragmentation happens, then tough :-)

>     o Also, justify why you're not using GRE. 24 bytes of overhead is better
>       than 28 plus there are 1000s of deployed routers that support GRE
>       tunneling. Some doing it in hardware.

Right, but can GRE work on top of UDP (and if so, can it be implemented in 
applications, without OS changes)?  And does it contain control packets 
(JOIN_GROUP, LEAVE_GROUP, etc.)?  That's why a dedicated UDP-based 
multicast tunneling protocol (UMTP) is used.

         Ross.