[Xorp-users] Access control and QoS for Xorp

[Pavlin Radoslavov]

> I am looking at how one might add Access control and Qos to multicast.
> I am thinking about modifying the PIM-SM routers on the network to
> send RADIUS requests whenever an IGMPv3 messages are received. The
> RADIUS server will then return accept or reject. If accepted, the
> RADIUS server will return QoS parameters which Xorp could then apply
> to the Linux kernel QoS functions at the same time it adds a new
> multicast route. If the required QoS resources are not available, it
> will not add a multicast route.
> 
> Is this functionallity possible in the current Xorp architecture?
> If so, where abouts in the source code should I look to add it?

James,

It should be possible with the following caveat.
Currently, our IGMP implementation is only IGMPv1 and v2.
We have IGMPv3 on our roadmap (see
http://www.xorp.org/roadmap.html), but it is scheduled for January
2006.

If, however, you don't need a full IGMPv3 implementation, but you
need only to receive the IGMPv3 messages, I belive it should be
relatively simple to add that to the IGMP module: you need to modify
Mld6igmpVif::igmp_process() inside mld6igmp/igmp_proto.cc
Then you just need to call Mld6igmpVif::join_prune_notify_routing()
to send the (S,G) Join/Prune signal to, say, the PIM-SM module or
the QoS module (see below).
Though, before going that path, can you confirm that you really have
to use IGMPv3, or IGMPv2 is also acceptable.

In term of adding the multicast forwarding entries to the kernel,
PIM-SM sends the appropriate XRL to the MFEA, and the MFEA installs
them into the kernel. Hence, if you want to add QoS parameters, you
have to modify the mfea/0.1/add_mfc4 XRL (see
xrl/interfaces/mfea.xif) to include those parameters. Of
course, you also have to modify the MFEA so it knows what to do with
those parameters. The MFC entries are written to the kernel by
MfeaMrouter::add_mfc() (inside fea/mfea_mrouter.cc).

The interesting part is who sends and receives the RADIUS requests
to/from the RADIUS server.
The easiest approach probably would be for the PIM-SM module to do
this, though it may not be the cleanest solution
(architecture-wise). A cleaner solution would be to have a separate
module (a QoS manager) that interacts with the RADIUS server, and
then it sends XRLs to PIM-SM with instructions what to do.
I believe the forthcoming policy manager can be extended to include
the QoS functionality as well, though currently it needs some
polishing before it is fully integrated with XORP.

In either case, the PIM-SM's behavior is controlled by RADIUS
accept/reject events, hence the PIM-SM module needs to be modified
to take those events into account.
You mentioned that the RADIUS server controls whether to
enable the installation of a multicast route.
This, translated into PIM-SM actions, means not only the
installation of the forwarding entries into the kernel, but probably
also whether any PIM Join messages are sent upstream (toward the
source or the RP).
There are several PIM-SM specific details that need to be
considered here, but those can be discussed once you reach this
stage. In any case, I don't see a show-stopper here, but it can be
an interesting exercise.

Regards,
Pavlin