[c-nsp] PPPoE efficiency

[Anton Kapela]

> I'm currently designing canopy wireless network. 

If you can wait until version 8 software is released, you'll probably be
more satisfied. Read further for more details.

> We are
> planning to occupy 100 users/AP, 6 APs/cluster and segment the network

> using cisco routers. I'm looking for a way to authenticate, authorize 
> and allocate bandwidth usage to the clients. I've heard about PPPoE, I

> just don't think that its efficient enough to use in canopy wireless 
> networks.

With approximately 8 more bytes of overhead per frame, I cannot imagine
this overhead will be felt. Also, canopy supports >1518 byte frames, so
in theory you could up the MTU's of your CPE router(s) if you wanted to
avoid shenanigans like tcp mss adjustment, etc. 

> I know
> this is a Cisco forum, I just thought that you guys had some 
> experiences with this.

My experiences with canopy multipoint on 6.x and 7.x code have been
favorable. However, there are some rough edges. Perhaps the most
important issue to consider in Canopy deployment is a lack of
'subscriber to subscriber' layer-2 isolation. Version 8 will finally see
some new smarts added to support things like 'rfc1483 half-bridge'
behavior. The goal here is to ensure that any unicast frame sent from a
customer SM cannot be switched towards any other users SM directly on
layer 2. The same goes for any broadcast or multicast frames sent from a
customer SM; these should not be re-propagated down to other SM's, and
only passed along the AP's wired ethernet link.

The only way to achieve this behavior today using 7.x software is by
configuring a vlan per SM. You could then create (perhaps bulk-create on
12.3T or later with 'range' command support) several hundred vlan dot1q
subints on your aggregation router, essentially providing isolated
layer-2 space per customer SM to your directly adjacent router. From
here, you could simply use DHCP or enable a PPPoE listener within each
subint. For more coverage of what I'm referring to with dhcp and
unnumbered subints, see [1].

Back to your original point: how to authenticate and allocate bandwidth.
I can see definite merit in using existing radius backends via pppoe to
support this, however, I'd strongly suggest you check into the BAM
software for canopy. Fwiw, BAM also supports externalizing user auth
(user is the SM's MAC, in this case..) via radius, as well as it's own
sql-interfaced user database. 

At any rate, a key issue with nearly every multi-access radio is
upstream timeslot contention (canopy uses most of 802.16-2004 and echos
docsis almost 1 for 1). I would not suggest that folks rely on virtual
templates or dialer interfaces alone to take care of bandwidth shaping;
this puts the bottleneck too far upstream. Bandwidth shaping should
happen, imho, as close to the user as can be achieved. Essentially, a
user could slam their upstream at whatever the air-rate happens to be,
only being limited once the pppoe frames get to the concentrator, which
would be much to 'late' to preserve access in the worst of cases (i.e.
new worm, virus, etc). 

Perhaps as important as staving off upstream storms is prioritizing
upstream access, which canopy can (as of 7.14-w, really...) do. It's
TOS/DSCP aware and does "the right stuff" by default with most voip
signaling and media protocols, assuming the user equipment so labels
said packets. If you implement rate shaping upstream of the SM and
sidestep the airlink, congestion won't ever occur in the SM, thus
negating any gains this prioritization could provide. 

Look to do whatever you can on the air link directly (bandwidth, auth,
etc), and pay close attention to the use of vlans for l2 isolation.
You'll end up having to 'touch' (either manually via web browser, or
perhaps via automated provisioning scripts) every SM at some point
durring deployment for some reason, so I'd strongly suggest using the
airlink features as they've been designed. 

-Tk

[1]
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft
/123t/123t_4/gtunvlan.htm