RAMA (aka SM, aka Simple Multicast) FAQ Q What is RAMA? A Root Addressed Multicast Architecture is an initiative to start thinking about a way to enhance the IP standard multicast service to offer several new features. In the same initiave, the proposers hope to simplify the operation of Internet-wide multicast by offering possible alternatives to running the full combiantions of PIM, MSDP, BGMP and the address allocation protocols. In exchange, there is additional complexity for the sending and receiving hosts, and modest changes to routers. There are at least 3 flavours of RAMA addresses: Express, SM and LSR. SM and LSR addresses require bi-directional trees. Express provides for single source only. Q What's changed A Nothing if you want to run with normal multicast; however, if you want to have the advantages (alleged) of the 3 schemes, a host needs to use a new API (option) - this may take the form of a different address tytpe parameter in connect/sendto/recvfrom/bind, or a setsockopt to set the first part(s) of the tuple(s) - though being able to find which (multicast) addresses that a received packet was sent TO would be useful (for ordinary multicast too:-) Q What are the host API to RAMA A Being worked on - two parts - a sender needs to specify a tuple (channel, group), or (RP, group) or {RP-list, Group}* a receiver needs to list/bind/setsockopt/join to same Q How is {RP, Group} allocation done A Can use MASC but without the conflict phase; or else can use manual config and advertisement through SAP or WWW or other, and modify host applications to look these up. For the list case, several levels of cnfiguration are expected to be needed (this seems to be a case of no free lunches). Q What is Simple Multicast? A The old name for RAMA - changed because it was misleading, and somewhat content free. Q Why change multicast? A We are not proposing changing existing multicast. The proposal is to enhance it. Q When might RAMA be relevant? A Not for at least 2 years. Ideally, RAMA would be part of the IPv6 set of multicast addressing styles. There would have to be v4 interworking too. Q Is RAMA in conflict with multicast deployment? A Not intended at all. Please deploy PIM, or any other reasonable multicast routing protocol as soon as you can! Q Who wants RAMA? A Some ISPs have indicated that Express (source access control) and reeiver counting are useful. A few have indicated that host control of RP use might be useful. (A cynical person might say: "In 1988, who wanted multicast?". Or even "In 1980, who wanted IP?".) Q Is there any running code? A Yes, there was a basic SM implementation, but based on CBT. There should be express code soon. The main (slightly important piece) Is the host API - work on this is underway. Q How important is RAMA? A its not obvious. Scaling multicast state in routers (if possible at all) would be far more useful... Q Does RAMA help scaling? A no, except possibly if most applications turn out to be express like Q Does RAMA obviate the need for MASC and other Malloc schemes (MZAP etc)? A No. Standard multicast will still require address allocation. Q Does RAMA improve the multicast address space? A Yes, though this may not be neccessary. Q What about fault tolerance? (if an RP fails, what can a poor host (sender or receiver) do? A One proposed model is to use anycast addresses for the RPs for the intra-domain case (i.e. lowest level of hierarchy) - see http://ana.lcs.mit.edu/dina/ Another option is to haev the RP candidate list retransmit eventually allow senders and receivers to move obver to the next candidate. Another is to have them cache this, and in an applicatio ndependneant way, use end to end protocols to detect lack of connectivity and switch to the next alternate etc etc - RAMA doesnbt have to dictate any of these - it lets the end system choose. so, For inter-domain we could choose a BGMP like scheme, or we could dense mode multicast to RPs etc...for a next level up, we could use anycast again as the number of RPs might be small - this is an area for simulation exploration. Q. Does RAMA elimiate the need for inter-domain multicast rotuing (i.e. do we only need PIM that does RAMA)? A No. there will always be other routing and addressing systems - inter-domain protocols are often mainly ways to support heterogeneity amongst routing protocols, not in and of themselves and architectural elegant piece of the picture. Q Does RAMA allow for better policy control than, say PIM/BGMP at the moment? A Not much, just a cleaner view of how it might fit together. Perhaps. Q. What about SAP/MZAP? A Needs more thought... Q Does RAMA need bi-directional trees? A SM yes, Express not necessarily.....the jury is still out here.... Q Isn't this all being done anyhow? A Yes, to some extent, but not in a transparant and cleartly articulated way as some people would like - RAMA is a framework for things that to some extent already exist or are being propoosed or worked on.... Q couldn't you do recvier counting in PIM anyhow (and with IGMPv3 even up to shared LAN hosts)? A Yes. thats the point. Q Wouldn't AIM (Brian Levin's proposed addressing architecture) be nicer? A Yes. Q What about vast numbers of very small groups? A see http://sscwww.epfl.ch/Pages/publications/ps_files/tr99_001.ps for a proposal from EPFL and Jean-Yves le Boudec's grouP