[Xorp-hackers] PIM and IGMP

Weaver John-JWEAVER1 John.Weaver@motorola.com
Tue, 5 Jul 2005 16:34:53 -0500


All of the PPPoE stuff should be transparent to the PIM/IGMP stacks.  We are
writing TAP devices that will interface all the IWF stuff to the stack.
Great news on the seperation.  Are you able to do simply through make
options or are there code mods that had to be done?

John

-----Original Message-----
From: Bruce M Simpson
To: Weaver John-JWEAVER1
Cc: 'Pavlin Radoslavov '; xorp-hackers@icir.org
Sent: 7/5/05 4:25 PM
Subject: Re: [Xorp-hackers] PIM and IGMP

On Tue, Jul 05, 2005 at 04:14:18PM -0500, Weaver John-JWEAVER1 wrote:
> Sounds great! Thanks!
> 
> We will not be using IGMPv3 for a while so that will not be a problem.
The
> other question is about seperating BGP, RIP, etc from the IGMP and
PIM.  Can
> we build the project without these?  I am looking for ways to reduce
code
> size and not sure if XORP can be picked apart?

Absolutely they can be built without BGP and RIP.

In fact in the Windows binary install I've been working on in
'skunkworks
mode', both BGP and RIP are optionally installed components.

If you're looking to further reduce code size, shared libraries may be
an
option, but currently there are issues with static constructors and data
which prevent this, at least for linkage on ELF platforms; some of the
library stuff needs to be reviewed for reentrancy, it's not something we
currently have the resources to do.

> Little nervous about the whole C++ thing as I am a C developer and our
last
> PIM/IGMP product was in C.  Guess I am going to have to ramp up fairly
> quickly.  My hope is through this experience I can become an active
> contributor.  I have working with switch/router hardware and drivers
for the
> last 5 years.  Would really like to get some of the hardware we use
and fire
> up and actual full fledged router with it.

XORP won't deal with any of the idiosyncracies of PPPoE or PPPoA with
your
DSLAM, but it will provide control plane functionality for IGMP and PIM.

XORP shouldn't have a problem controlling forwarding of multicast
datagrams
over the DSLAM's interfaces as long as each interface is visible to the
Linux kernel as a regular point-to-point network interface -- that is,
PPPoE/PPPoA encapsulation issues, AAL5 framing for DMT lite etc will be
*your* problem. :-)

Whilst I'd like to teach XORP to deal with ATM VCs directly I don't have
time right now. :-)

BMS