[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

simple multicast mail list




1. i got tired of typing all those names - welcome to the simple
multicast mail list - to leave, send a message to
sm-interest-request
with 1 line in subject or content saying "unsubscribe"

2. some (random collection of)
thoughts i had on the train yesterday from liege to london

i'd really like to re-visit HPIM in the context of core allocation
- - given SM, we can experiment with core allocation nicely -
hierarchies of cores can be very neat to enable core migration
(somethign that lets us do dynamic load balancing which may match
dynamic group membership, but also lets us do fault tolerance)
the current heriarchical management of the address/route
infrastructure which gives an approximate set of hints about actual
admin and topology is
AS/Area/Prefic
so a small number of levels to a core hierarchy would do - then
internal to each level, one could use a YAM like approach to candidate
core selection (i.e. use legacy multicast from hosts to cores and core
to core...)

so what to do in the event of core failure? basically, the problem
with SM is that while some sender/receiver tree will still function,
the route to the core will not be there - there are about 4 cases to
consider
1/ the network the old core was on is still there - then another core in that
net can (just using unicast routing) discover the main core is buted,
and re-allocate itself to have the IP address of the old core
2/ the net (or prefix) is down/uncreacable - so a core on another net
can add the net and address and advertise itself as a LONGER match
than the old core (until it comes back) - its necessary to do this so
that the hosts on the old net dont suddenly become apparently reacable
when they arent
3/ an area is busted - same as 2 though
4/ the old core AS  is busted - then we need to have a inter-AS Policy
to let anopther AS's core somewhere take over as per 2/ - this is
nastier! and needs more thought...