Thus spake Kevin Benton
I don't know if the packet or TDM bus is designed to handle that much data, however.
Unfortunately, I believe the answer to that is, no, it isn't designed to handle that much data. The TDM bus on the chassis has (if I remember correctly) 512 timeslots...a fairly significant number short of the 672 needed to handle DS3 ingress. :/ Now, in theory, you could change the clocking in the chassis and crank the number of timeslots higher, and assuming that 3Com has overengineered the TDM bus like they did the rest of the chassis, this might even be feasible. I'm certainly not a guru when it comes to this area, so I don't know for sure, but I wouldn't rule it out. The downside of this is that you probably would not be able to have any of the current cards that use the TDM bus in a chassis with cards that would use the faster TDM bus as they pull their clocking off the bus itself and the current crop of cards (unless they're also rather overengineered) couldn't handle the higher speed clocking. Minor drawback, and one that I, for one, would certainly be willing to live with. There are probably other obstacles to this that I'm not aware of, but the theory seems pretty simple. :) The thought that I had was that you had a master/slave ds3 card setup...master in one chassis took the ds3 in, split off half the channels and sent them across the packet bus to the DSP cards, then the other half of the channels were daisy chained to another chassis where it connects to another ds3 ingress card and the rest of the channels were handled. Shoot, if this were done right, you could then daisy-chain that over to a third chassis as a full hot-spare chassis...if one of the first two chassis failed, the calls would get passed through to the third. I discussed all of this with Tom Goodman when I was up for Networks3, so there's at least one person in 3Com who I've talked to about these ideas. :)
Let's see... 28 / 2 = 14. If the DS3 card took up one one slot, that'd be 15 slots with the DSP's. Hmmm :) One for the serving gateway card, and one for the NMC... :) Sounds like just the right size to me... Am I the only one who thought of this? :)
Ai...not sure I like the idea of a full ds3 worth of calls terminating on a gateway card with no hot spare available. :/
The only real disadvantage to doing this is putting so many eggs in one basket with the chassis being required to be up.
Particularly the gateway card (HiPer Arc, or whatever a beast that could handle 600 calls would be called).
If we were going to put that much $ into a box, though, I'd definitely want to be able to peel off some of those DS1's into external RJ45's to be used by other CSU/DSU's so we could put DAP customers, etc. on it.
I've thought that the DSP's should be more general purpuse anyway. Take the DSP NAC, and rather than making it a T1/PRI/modem board, use that mondo processing power there (and with 3 PPC's, its got plenty) give it a T3 NIC and let it do packet T3. Then you could also use those PPC's as a distributed route-cache/forwarding engine, or a compression or encryption engine. Certainly it would at least do the framing work that it currently does with PPP. Its quite possible that you could even relegate the HiPer Arc to being a control engine type of thing, where the routing protocols and such are processed by the Arc, a forwarding table is built which is then pushed out to the DSP cards which do the actual forwarding. This isn't exactly unheard of in other vendor products as it is. :) Most vendors are going to a processing engine, and one or more forwarding engines...certainly a DSP/Arc equipped chassis has more than enough processing power available to handle a huge amount of throughput/pps. Careful coding should let you have transparent failover of the Arcs that way too. You could at least do this for plain packet forwarding...you'd lose telnet sessions to the Arc, probably BGP sessions (assuming BGP is available then), but with a draft I saw the other day...kind of like a soft restart of BGP...you could prevent that from stopping packet forwarding even. There are so many possibilities here...I don't think any one person can conceive of them all...that's one of the reasons that I've been trying to get people to post some blue-sky thinking here...give 3Com some ideas of what could be possible. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.