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

[Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>]

so here's the scoop

somewhere (in www, session advertisement, in skywriting, in DNS if we
can close that discussion:-)
a multicast address is advertised

if its SSM or its PIM SM, then the RP or source are advertised 

so a non multicast receiver can find _A_ unicast (or if anycast RPs
are used, even maybe an anycast, though i guess someone on anISP that
doesnt allow end users multicast probably doesnt let them use other
useful things too - hey, they probably are behind a nat too:-)

anyhow, so rathwerthan something complex for the end user, lets
propose this

1/ send a UMTP request to the source (if ssm) or RP (if PIM SM) p sort
of same thing

2/ the source (or RP) propagates the request down the tree (by
multicast, of course)

3/ the first on tree router that does IP to UDP tunnels says "OK/ACK", and
propgstes this new message up the tree to say "i'm handling it" and
down the tree too (deal with interdomain routers somewhere there
somehow...)

4/ the on tree router handling it send s the unicast response to the
user and starts forwarding data....

5/ UMTP leaves are sent direct to this ontree router.

Handovers:

ontree router is now taking place of the SSM source (or RP) in the
example above.....follow procedure again, but with a bit in the UMTP
header to say "handover" ....

Scope: might want to scope how far up and down a tree a handover can
go....

Management:-) 

ontree UMTP capable routers may want to load balance - to this end,
they need to exchange load information. easy. they can all do
multicast. so
i) we assign a new group/rp, or one of them is a source/distribution
point.
ii) we build an IP-multicast tree of on-data-tree UMTP-capable routers
from the RP or "designated root" (actually, its a strict subtree of
the data tree)
iii) we map at the UMTP points on it, the additional branches and mark
the UMTP degree (a single number, for each UMTP-capable router)

this can be used to do some balancing if we want....(how to do
balancing is subject for further study - for example, it aint obvious
at all:-)

now i know some Big Router Vendors might say that this is tricky to do
in their boxes - but theres nothign to stop someone selling a
streaming server that also peers via the IGP and then runs PIM, and
then does this stuff.....


if we don't like/support UMTP, then any other IPmc to unicast
techniquee can also apply (fill in this form here:- [...] )

comments?


In message <756.983099427@cs.ucl.ac.uk>, Jon Crowcroft typed:

 >>
 >>i like the handover stuff - i think this is what is missing fro mthe
 >>other auto-tunnel draft - we need to think about
 >>a) giving on tree routers a choice about which of them is the initial
 >>point of grafting a unicast user on
 >>b) letting them change their minds under load....
 >>
 >>this work helps us think about this !
 >>
 >>i sort of envisage a hybrid between traceroute and rsvp - basically,
 >>you send a tunnel request/join towards one of
 >>i) a known on tree router (configured)
 >>ii) the source (e.g. for ssm )
 >>iii) the rp (pim sm)
 >>
 >>as it shoots by various routers that know about the s,g, they can
 >>respond or not, and can modify the inflight request to say so so that
 >>upstream possible tunnel brokers can act on that....
 >>
 >>maybe?
 >>
 >>j.

 cheers

   jon