> If you're in the UK, then that's likely. Nope, not in the UK.
> If that's the case (and you have a non-routable > address assigned to > your system), then I don't see why you'd configure > NAT on the Solaris > system -- unless the NAT in the ADSL box has > problems. My ADSL "modem" has two interfaces. The external interface has a routable static IP address, with IN PTR configured at the ISP and IN A being served by my DNS servers on the DMZ and all that jazz. The internal interface on the "modem" has a non-routable IP address, so packets in the "modem" get NATted before they exit on the outside interface. The catch is that the ADSL "modem" only has one EtherNet port, so only one system can be connected to the Internet. Well, no problem, IPFilter to the rescue! By NATting all LAN and DMZ packets to the external interface of the FW (also a non-routable IP address on the same subnet as the "modem"), I trick the "modem" into thinking that there is only one host connected, when there is in fact an entire server farm and two DMZs behind that one IP address. But it's still wasteful and overhead to perform the NAT twice for every packet coming in or out. > At the lowest level, DSL links essentially just > provide a synchronous > bidirectional (full duplex) communications path. In > order to put > packets on there, you need some sort of framing -- > that can be HDLC or > AAL-5 plus ATM. If I understood correctly, what they're doing is is transporting TCP/IP over ATM. > To use routers, you'd have the head-end termination > break out the bit > stream (as is done today), but instead of running > that into an ATM > switch, just run it into an access router. The > router can then run > HDLC over the link, and PPP works fine on that. But could they have run EtherNet all the way, or is the copper line the problem for EtherNet? I mean the last mile. And once at the CO, just normal EtherNet routers and fiber back to the backbone? > The result is lower overhead -- roughly 1% for > maximum-sized PPP > frames on HDLC with ACFC/PFC turned on versus more > than 10% for the > ATM cell tax and another 2.4% for AAL-5 internal > fragmentation. > > To deploy it, you'd need IP routers every place where > you currently > have ATM switches, and instead of backhauling those > VCs to some > separate ISP access device, you'd, well, need to do > nothing special. Yep, and routers and cheap nowdays; certainly cheaper than they were a few years ago. > The management part has several embedded issues: > > - If you don't have VCs, then you can't > double-charge for the access > mechanism by having a separate ISP entity; access > provider and ISP > become one. That likely runs afoul of several > important > regulatory issues in various places, despite the > obvious benefit > for users of not having to pay twice just to add > an extra > bottleneck. > - Metering and billing need to be performed at the > per-link level, > because there's just one PPP session, and access > billing tends to > be done based on PPP plus backend AAA. The ATM > mechanism gives > you a way to bill separately for each remote > endpoint, even if > they're on a single DSL line (should you choose to > do so). Yes, but why would we need to meter? Yes, there are still fascist-like telcos out there that measure your monthly traffic, but I predict that that billing/business model has no future. In the future all ADSL or SDSL or whichever technology replaces it will be flat rate. If we speculate that my assumption is true, what would need to be metered? > as I've said, I've never seen DSL links without > ATM. It could be > done, but it's just not. I can easily imagine why, when I look at the "christmas tree experts" in the IT field here. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
