[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: multicast-transition (fwd)
It must be too early to tell my detail design, though.
I've been doing my research around this topic, to implement SSM very
easily. My idea just uses modified IGMP and may not require multicast
routing protocol.
Protocol changes are;
o. Modified IGMP defines new three IGMP types, IGMP Reply,
IGMP Ack, and IGMP Data.
o. Modified IGMP can be sent as a unicast packet.
e.g., as for receiver's join, followings are basic deals;
o. Receiver just sends IGMP Report(Join) to an interesting
sender by unicast.
o. Sender tries to send IGMP Reply back toward the receiver
after receiving IGMP Report(Join).
o. A new-IGMP-capable-intermediate router located between
sender and receiver steals this IGMP Reply and sends IGMP
Ack back to the source address of the Reply packet.
o. Above intermediate router creates (S,G) state which
consists of iif, oif list, and destination list.
(oif is given by unicast routing table, or MRIB if you want
to use additional multicast routing protocol.)
o. Above intermediate router sends IGMP Reply toward the
receiver continuously.
o. After sender receives IGMP Ack, he sends IGMP Data which
encapsulates IGMP header and UDP data to Ack sender.
o. Destination address of IGMP Data can be changed according
to the next destination (i.e. neighbor node to forward
Data). The destination is Ack sender if the neighbor is not
on a same LAN, and it is G if the neighbor is on a same LAN.
o. ...
My proposal has several important points.
1. It doesn't require any multicast routing protocol. Only supporting
new IGMP by sender and receiver is required.
2. If there is no intermediate router which supports new IGMP within a
sender and receiver path, it looks like sender sends unicast packet
whose protocol type (ip->ip_p) is IGMP (#2). So, it must be so easy
to deploy.
3. Because only unicast route is used and data path is created from
the sender toward each receiver, it is very scalable and
bi-directional.
4. Not so difficult to implement. (I believe so.)
5. It is easy to implement on IPv6, too. (Specific needs.)
6. It doesn't require some tunneling mechanism. It requires simple
encapsulation technique. (You may say I use tunneling but I don't
like to say "tunnel", because, to me, tunnel just gives an image to
make some stateful or keep track of the connection, anyway.:)
Of course, there are some immature/unsolved points.
1. Interoperability between current multicast routing protocol.
2. Scalable timer management.
3. Security.:)
... and so on.
Any comments, even objection, would be welcome.
--
Hitoshi Asaeda