ADSL is almost universally implemented as an ATM data-link layer running on top of a high-frequency copper carrier physical layer. A second data layer, usually Ethernet (sometimes with PPPoE) but sometimes PPPoA (PPP over ATM) is implemented on top of this.
In Australia, and presumably elsewhere, the incumbent telco (Telstra, in Australia's case) has a monopoly on most of the POTS lines running into people's houses. This, naturally, means that the ADSL signalling equipment at the exchange is under their control. So what happens if you want to sign up with a competing service?
The 'traditional' way to do it is for Telstra to provision different VPI/VCI pairs (more on these in a minute or two) which get switched via ATM back to ATM equipment at the competitor's office. The ATM is then thrown out, and Ethernet, PPPoE or PPPoA can be run over the VC between ISP and Customer. This model sucks.
Lately, Telstra has been trying to flog an even less effective 'pro-competition' model, L2TP. In this scenario, telstra terminates the PPPo[EA] session for you and hands the PPP frames back to you through their ATM network to your L2TP server, which handles the PPP encapsulation, radius, etcetera. This model also sucks.
The third alternative which we haven't really seen in Aus, but I'm informed is quite prevalent in other countries, especially the 'ol US of A, is where competing carriers co-locate DSL equipment at the incumbent's exchanges, and individual copper pairs belonging to subscribers are patched into the correct carrier's DSLAM. There have reportedly been problems involving the Bells doing sneaky, underhanded and just downright mean things to their competitors, such as 'accidentally' un-patching several hundred pairs at one of the distribution frames between DSLAM and customer.
In order to understand the model I propose below, you'll need to understand a little bit about how ATM works, and why it works. If you know these things already, feel free to skip the next couple paragraphs.
ATM is a cell-routed data link protocol which has similarities with ISDN, Frame Relay, and, surprisingly TCP/IP. When an ATM 'end device' wants to send data to another ATM end device, it fragments data-link frames into 48 byte cells, and prepends a 5 byte header which includes a cell checksum, and the destination Virtual Path Identifier and Virtual Circuit Identifier. The intermediate switches have switching tables which contain instructions to the effect of 'cell with VPI/VCI x/y and input interface z, gets output with VPI/VCI a/b and output interface c'.
ATM also supports quality of service, by specifying certain types of Virtual Circuit in part of the specification known as 'ATM Adapatation Layers.' These, however, are unimportant here; all that's required is to realise that we're talking about Variable Bitrate Cell-Switched data, which meets the criteria of AAL5.
Now, the cell switching tables can be built in one of two ways. Either statically, by hand (on each intermediate switch - this becomes something of a nightmare eventually); or by using ATM signalling to dynamically build virtual circuits between two end devices connected to the same ATM network. In order for ATM switches to know which destination device a given source device is talking about, it needs some concept of addressing.
Enter the NSAP address. This is usually 20 bytes long, and has the format (prefix).(station address).(selector byte). The selector byte is almost always zero and is used to differentiate different ATM applications running on the same device. We can safely ignore it. The prefix is specified by the ATM switch the device is connected to, and has a variable length. The E.161 standard specifies a 13-byte prefix length. The station address is much like a LAN station address and is six bytes in length.
Now, after an end station registers with its directly connected switch, it sends a packet identifying its station address to the switch over well known VPI/VCI pair 0/16, which is referred to as ILMI (Integrated/Interim Local Management Interface.) The switch then advises the end device of its prefix, and all is well.
Amongst themselves, the switches run a link-state routing protocol to advise each other of which prefixes they can reach. Eventually the network converges.
Eventually, an end device wants to set up a virtual circuit to another end device, so it announces its intention to the switch via the ILMI mechanism. Based on its routing table, the switch sends a similar request to its next-hop switch for the requested prefix, and eventually the connection request reaches the other end station. After acknowledgements are sent back in the other direction, the switch announces the VPI/VCI pair for the newly-built circuit to the end device, and all is well. Until the circuit is torn down (again via ILMI,) the VPI/VCI pair for the circuit functions identically to a hard-coded PVC.
Now, back to ADSL. Since the entire network is built on ATM anyhow, why not simply connect your ADSL ISPs to the ATM network of whoever owns the physical copper, and let the end user initiate an ATM VC to their ISP of choice. In this way, an NSAP address would function much like an 'ADSL Phone Number.' You could either build the connection and then frame ethernet over it (much like ATM LANE, but without the complications,) or you could simply run PPPoA over the SVC. This would fit in very nicely with the current 'dial up' model that most internet users are used to, albeit at higher speeds.
ADSL ISPs would need:
- ATM circuit into national carrier (as opposed to ISDN lines into national carrier for dialup modems)
- Slightly larger connection to the Internet (as opposed to what they have to support dialup).
As long as these two constraints are met, the whole thing would function flawlessly.
The only problem I can forsee with this method is that a user is likely to balk at a phone number which looks something like
but then, you could hide that from them with an Install CD. The current VPI/VCI settings are hidden from them anyway.
How about it?