One very very important thing that commercial vendors "get" is the fact that a user of such a package is probably NOT accountant, and needs extensive hand-holding when dealing with accounting matters which often have legal implications.
Commercial packages understand this. QB will offer to set up a chart of accounts based on 'interview'. QB will warn you if you are entering things that don't make sense from accounting standpoint.
Writing a ledger app is very easy. Writing an easy-to-use app which provides assistance at every step of the way is not.
This is probably the only case where I think that hand-holding is essential for a product, and why QB is still the only commercial software I use now.
Actually, now that I have acquired more familiarity with accounting concepts, I may migrate to SQL-Ledger, however, these are things that matter for me:
a) Payroll. Its a real pain to compute all the various taxes by hand. Its a real pain to track all changes to tax law for your state to be in full compliance. Now, if sql-ledger guys wanted to do payroll, they'd need to track law changes across all 50 states. Somehow, I don't think it'll ever happen.
b) Compliance (which relates to payroll). Certain reports (941,W2,940, state forms,etc) have to be _right_. Most of them are payroll-tax-related. The penalties are severe and "your honour/officer, my linux software made a mistake" does not cut it.
This was an extremely oversimplified view, more like "I think I need to have bar want to do foo, but I'm clueless what anything else".
There are many issues at work:
a) Assignment of PI (Provider-Independent) addresses:
Back in '94, as an end user, you were able to get a netblock directly from ARIN. Then, this block could be advertised (by BGP4) by your upstream[s], and thus you got connectivity. The problem here lays that these IP addresses were nonaggregatable and led to exponential growth in routing table size. (see http://www.telstra.net/ops/bgptable.html up to 1994). Thus, CIDR was born, and hierarchical assignment became the rule. Your upstream (call it foo) gets the IPs from their upstream (call it bar), and the whole internet sees needs only one routing table entry to reach all of bar's customers.
b) ingress filtering (filtering of traffic from customers to make sure only the source IP that are assigned to them are used). Yes, most ISPs do ingress filtering now, and it is now considered a BCP (best current practice) to do this (there's an RFC on that). Again, this is for a damn good reason: Without filtering, DoS attacks cannot be traced to their source, if one is spoofing the source addresses. With filtering, at least you know that the source IP address is likely to be the one attack is launched from (or one of 0wned machines attacking you).
Its well known that ingress filtering makes multihoming harder, as your upstream has to open up their ingress filter for the IPs that are assigned to you by entities OTHER than your upstream (say, your other upstream).
Since apparently you intend to advertise your network via BGP4, all ISPs who will talk BGP4 to you will have no problem relaxing their ingress filters. If all you have is a DSL line, you'll have fat chance of getting your upstream to talk BGP4 in the first place. See below for strategies to do this without BGP.
c) Even if you managed to get your upstreams to turn off ingress filtering and advertise your network via BGP4, you still may run into problems because many ISPs do not listen to network announcements less than/20 (Sprint and Verio are two notable cases). (Thus, if you have an IP range IP_A from ISP A and IP range IP_B from ISP B, and both ISPs advertise both ranges, you can still run into problems when one of htem goes down). Fortunately, lately, the wind started to change, and I think sprint already relaxed their requirement to/24.
Bottom line is: if you want to have your "own" IP address range, you must advertise it via BGP4. If you can get your upstream to do that, you can get them to relax their ingress filters, thus your original complaint is silly.
Now, if all you have is two DSL lines and no cooperation with your upstream you can do the following (sometimes called DNS-based multihoming), _for inbound traffic_:
You set up two nameservers (A and B), one on each of the IP ranges that you have (range_a and range_b). Make all of the entries given out by nameservers have TTL of 5 minutes.
Make each nameserver have a DIFFERENT zone, containing only IP addresses on that range. (Ex, nameserver A will have an entry for www pointing to an IP from range_a, nameserver B will point to an IP from range_b.(both nameservers can actually run on same machine, bound to different interfaces).
Then, whenever someone tries to reach www.yourdomain.com, they'll hit one of the nameservers. If the one they hit first is down, they'll hit the other one, and get an IP address from the _working_ network. Voila, you are still reachable when one connection goes down.
Then, if you don't want your servers to actually have two IP addresses (one on each net), you can do some trickery with iptables/ipchains to redirect traffic to a single IP (probably on private network).
For the outbound traffic: All you have to do is to NAT your traffic to the correct interface/IP range (the one that's currently working). That is not very hard to do with a bit of shell scripting.
Actually, things are a bit more complicated because of this: Your machine (main firewall or whatever) that contains all these interfaces, normally has one routing table. Choosing of the correct interface is done by lookup of DESTINATION IP. Now, assume a packet comes over to IP_B. You _must_ make sure that it will go out BACK on interface B (if you send a return packet with an IP_B source address over ISP_A, it'll discard it because of ingress filtering). This is hard: again, remember, routing does not depend on your _source_ address, it depends only on destination address.
So, how do you solve it?
Luckily, Linux has policy routing, which allows you to have multiple routing tables and choose between them based on some criteria, in your case, it will be source IP. You'll set up two routing tables, one with default route pointing to ISP A, one to ISP B, and a rule saying "If a packet has a source on IP_A, use routing table A, if not, use routing table B"
(see iproute2 documentation for details)
Well, I think I should write a HOWTO on that...I glossed over quite a lot of details here.
Here, the tradeoff is being able to quickly determine the files belonging to a particular package/software vs time spent managing PATH/LD_LIBRARY_PATH and all sorts of other entries.
Also, the question is how should the files be arranged? By type (bin, share/bin, lib, etc) or by package?
In Linux (redhat/FSSTD), the emphasis was placed on arranging files by type, and the file management was declared a separate problem with rpm (or other package managers) as a solution.
There is another solution which combines best points of each:
Install each package under/opt/packagename. Then, use unionfs to join all/opt/packagename's under/usr tree. Thus, you still will be able to figure out which package has which files without using any package manager, but at same time, you are provided unified view of all packages installed.
Unfortunately, unionfs never worked on linux, and on other operating systems its very tricky. (Such as, how do you ensure that underlying directories will not have files with same name? And if they do, which one will be visible? What do you do when a file is deleted? etc).
Yes, if cosource was alive, I might've done it through them.
On other hand, I don't feel that I need a mediator between me and developer[s]. Yes, in direct contract between me and developer, there's slightly more risk of non-payment or non-delivery, however, that risk will be limited by clearly marked milestones.
Patents Yes, this is an issue. No, I don't have commercial backing.
The full list of patents claimed by various companies in relation with ITU recommendations is here:
http://www.itu.int/ITU-T/dbase/patent/files/Patl is t_16Nov01.pdf
No, ITU does not have 'essential patent' list for any of modem algorithms. Yes, there are companies that claim to have patents related to implementation of v.34 and v.90 (13 patents for v.34 and 26 for v.90). I'm investigating which precisely patents are these (some of them have patent numbers, some don't).
I'm still researching this issue...
Hardware interfacing: Yes, this is separate from the project. Hardware is abstracted by "offhook/onhook, read/write PCM data", to simplify the development.
Drivers for specific hardware will be written later.
Jamie, first I have to thank you for this very informative post which clarifies for slashdot crowd many issues involved.
Re: Working on the code Yes, I obviously know about your work and mentioned it as one of possible bases to start off development, and I also know that it has been progressing slowly. If the bounty causes you to spend bit more time on the code (and join a team who'll do certain other pieces), that'd be the best possible outcome.
Re: Homologation This is a tricky thing. Yes, you are right, legally, both hardware and software (in case of soft modem) must be certified for connection to phone system. I've been thinking how to handle this (as I definitely won't be able to fund certification of each individual hardware piece+software piece), however, I don't have clear handle on it.
Hopefully, individual modem manufacturers will be receptive to the idea "How about you make your modem accessable to 10 more million people at an expense of (whatever part 68 certification costs)", at no risk to your intellectual property.
I'm not even sure how (or whether?) do they certify each new revision of WinModem software. Is only software certified? (not likely!).
Is each combo of hardware+software certified (expensive!). Do manufacturers certify one version only? (most likely).
I'm going to find out, hopefully FCC will be receptive. If the latter is the case, that's the strategy we'll pursue.
The DSP that is in the modem will _not_ be used for the purposes of this project. Thus, we can abstract from modem hardware on the level of "Read/write PCM data, take offhook/onhook". (very simple API). Even dialing falls under generation of PCM samples.
Well, I said "background". This does not mean "10 college-level courses and 5 years of experience".
Background merely means you should already have done a project involving digital signal processing. This may range from developing software Caller*ID device (FSK demod) to someone who developed ADSL hardware.
Yes, that's correct (no use of DSP will be done). The reason behind it is to simplify the work, and to avoid getting into details of each individual DSP's assembly/programming.
Hardware-specific code is actually out there for many devices. At any case, reverse-engineering of each piece of hardware can be done later once this is completed.
No, I am not related to any manufacturer of any winmodem-related device.
Sorry, to clarify: This particular restriction is to make sure the code will be developed in foreseeable future.
This is not a toy project. The knowledge needed to complete it is significant. I wouldn't expect someone who already HAD implemented a modem, but I expect someone who knows what signal processing is all about.
I'm sure that Linus had some knowledge of OS concepts when he started writing Linux, by that, I mean knowledge of things like design of scheduler, message passing, etc, etc.
In the same way, I expect that people who would develop this code would have knowledge of filter design (FIR, etc), and
To my knowledge, there are no patents that would hinder this particular development.
Notwithstanding this, there ARE patents in the general area:
SMLink has bunch of patents, but they are all (again, to my knowledge) in hardware-chipset area, not in driver area.
PCTel also has patents in the same area.
Rockwell and Agere have patents in DSP-modem area.
There are patents for the algorithms involved in v.34 and v.90, however, I believe they all can be either avoided (by implementing differently), or denied by presenting prior art, however, they are the biggest threat.
These patents are owned by PCTel and SMLink. I'm still in process how to avoid them.
As a matter of fact, there was a ternary computer built in Russia, called Setun' (apostrophe signifies a soft n).
Russian translation of Knuth's Volume 2 was quite funny. Knuth is saying that "Somewhere, some strange person might actually build a ternary computer". The russian translation had a translators footnote "Actually, it has been built in russia in 1960s".
See this page for more information about setun:
http://www.computer-museum.ru/english/setun.htm
Multiple reasons:
a) DSLreports information can be wrong. Many providers advertise 'we can get DSL to anything' while they can't do it really.
b) It could be that actually BA doesn't have their DSLAMs in the CO, but other CLECs do. Then you are in luck.
But at any case, if you are too far from CO, you will not be able to get DSL through anyone.
Actually you can't just switch, since Covad and Concentric use completely different modulation (SDSL modulation, even when the service is claimed to be "ADSL". Its actually a capped SDSL)
This is called "ingress filtering" and has been advocated in IETF workgroups and on NANOG for last 3 years.
See following RFCs: http://www.faqs.org/rfcs/rfc2267.html ('98) http://www.faqs.org/rfcs/rfc2827.html ('00)
Many 'big' ISPs apply that to their leaf connections at the edge routers, smaller ISPs usually don't do that, which is surprising since its actually simpler to do if you are small. (less edge routers;)
The only problem with such filtering are people who are dual-homed and have asymmetric routing: I.E. Customer has to connections, to ISPs A and B, and may be sending outbound traffic with source-addresses in B through A's connection. This is legitimate, there are many uses for it: 1. Satellite one-way connections 2. 'overflow' routing 3. load-balancing of outbound traffic
So, ISP has to blow holes in their filters for such customers. (Which we do at customer request).
Swap is never really reused anyway. Swap is encrypted to protect from stolen-harddrive-attack.
Re:"How do you like your OS?" "Slow, please."
on
OpenBSD 2.7 Released
·
· Score: 2
No. Do basic math: Swapping means at least 5 ms delay to throw data to disk, which is about as slow as anything can get. In these 5ms, you can encrypt quite a lot of data even with something as slow as DES. Blowfish would be blazingly fast.
In short: Encryption performance is about as fast as drive I/O, and initial delay on IO makes it unnoticeable.
Slashdot Mirror
One very very important thing that commercial vendors "get" is the fact that a user of such a package is probably NOT accountant, and needs extensive hand-holding when dealing with accounting matters which often have legal implications.
Commercial packages understand this. QB will offer to set up a chart of accounts based on 'interview'. QB will warn you if you are entering things that don't make sense from accounting standpoint.
Writing a ledger app is very easy. Writing an easy-to-use app which provides assistance at every step of the way is not.
This is probably the only case where I think that hand-holding is essential for a product, and why QB is still the only commercial software I use now.
Actually, now that I have acquired more familiarity with accounting concepts, I may migrate to SQL-Ledger, however, these are things that matter for me:
a) Payroll. Its a real pain to compute all the various taxes by hand. Its a real pain to track all changes to tax law for your state to be in full compliance. Now, if sql-ledger guys wanted to do payroll, they'd need to track law changes across all 50 states. Somehow, I don't think it'll ever happen.
b) Compliance (which relates to payroll). Certain reports (941,W2,940, state forms,etc) have to be _right_. Most of them are payroll-tax-related. The penalties are severe and "your honour/officer, my linux software made a mistake" does not cut it.
This was an extremely oversimplified view, more like "I think I need to have bar want to do foo, but I'm clueless what anything else".
/20 (Sprint and Verio are two notable cases). (Thus, if you have an IP range IP_A from ISP A and IP range IP_B from ISP B, and both ISPs advertise both ranges, you can still run into problems when one of htem goes down). Fortunately, lately, the wind started to change, and I think sprint already relaxed their requirement to /24.
There are many issues at work:
a) Assignment of PI (Provider-Independent) addresses:
Back in '94, as an end user, you were able to get a netblock directly from ARIN. Then, this block could be advertised (by BGP4) by your upstream[s], and thus you got connectivity. The problem here lays that these IP addresses were nonaggregatable and led to exponential growth in routing table size. (see http://www.telstra.net/ops/bgptable.html up to 1994). Thus, CIDR was born, and hierarchical assignment became the rule. Your upstream (call it foo) gets the IPs from their upstream (call it bar), and the whole internet sees needs only one routing table entry to reach all of bar's customers.
b) ingress filtering (filtering of traffic from customers to make sure only the source IP that are assigned to them are used). Yes, most ISPs do ingress filtering now, and it is now considered a BCP (best current practice) to do this (there's an RFC on that). Again, this is for a damn good reason: Without filtering, DoS attacks cannot be traced to their source, if one is spoofing the source addresses. With filtering, at least you know that the source IP address is likely to be the one attack is launched from (or one of 0wned machines attacking you).
Its well known that ingress filtering makes multihoming harder, as your upstream has to open up their ingress filter for the IPs that are assigned to you by entities OTHER than your upstream (say, your other upstream).
Since apparently you intend to advertise your network via BGP4, all ISPs who will talk BGP4 to you will have no problem relaxing their ingress filters. If all you have is a DSL line, you'll have fat chance of getting your upstream to talk BGP4 in the first place. See below for strategies to do this without BGP.
c) Even if you managed to get your upstreams to turn off ingress filtering and advertise your network via BGP4, you still may run into problems because many ISPs do not listen to network announcements less than
Bottom line is: if you want to have your "own" IP address range, you must advertise it via BGP4. If you can get your upstream to do that, you can get them to relax their ingress filters, thus your original complaint is silly.
Now, if all you have is two DSL lines and no cooperation with your upstream you can do the following (sometimes called DNS-based multihoming), _for inbound traffic_:
You set up two nameservers (A and B), one on each of the IP ranges that you have (range_a and range_b). Make all of the entries given out by nameservers have TTL of 5 minutes.
Make each nameserver have a DIFFERENT zone, containing only IP addresses on that range. (Ex, nameserver A will have an entry for www pointing to an IP from range_a, nameserver B will point to an IP from range_b.(both nameservers can actually run on same machine, bound to different interfaces).
Then, whenever someone tries to reach www.yourdomain.com, they'll hit one of the nameservers. If the one they hit first is down, they'll hit the other one, and get an IP address from the _working_ network. Voila, you are still reachable when one connection goes down.
Then, if you don't want your servers to actually have two IP addresses (one on each net), you can do some trickery with iptables/ipchains to redirect traffic to a single IP (probably on private network).
For the outbound traffic: All you have to do is to NAT your traffic to the correct interface/IP range (the one that's currently working). That is not very hard to do with a bit of shell scripting.
Actually, things are a bit more complicated because of this: Your machine (main firewall or whatever) that contains all these interfaces, normally has one routing table. Choosing of the correct interface is done by lookup of DESTINATION IP. Now, assume a packet comes over to IP_B. You _must_ make sure that it will go out BACK on interface B (if you send a return packet with an IP_B source address over ISP_A, it'll discard it because of ingress filtering). This is hard: again, remember, routing does not depend on your _source_ address, it depends only on destination address.
So, how do you solve it?
Luckily, Linux has policy routing, which allows you to have multiple routing tables and choose between them based on some criteria, in your case, it will be source IP. You'll set up two routing tables, one with default route pointing to ISP A, one to ISP B, and a rule saying "If a packet has a source on IP_A, use routing table A, if not, use routing table B"
(see iproute2 documentation for details)
Well, I think I should write a HOWTO on that...I glossed over quite a lot of details here.
Here, the tradeoff is being able to quickly determine the files belonging to a particular package/software vs time spent managing PATH/LD_LIBRARY_PATH and all sorts of other entries.
/opt/packagename. Then, use unionfs to join all /opt/packagename's under /usr tree. Thus, you still will be able to figure out which package has which files without using any package manager, but at same time, you are provided unified view of all packages installed.
Also, the question is how should the files be arranged? By type (bin, share/bin, lib, etc) or by package?
In Linux (redhat/FSSTD), the emphasis was placed on arranging files by type, and the file management was declared a separate problem with rpm (or other package managers) as a solution.
There is another solution which combines best points of each:
Install each package under
Unfortunately, unionfs never worked on linux, and on other operating systems its very tricky. (Such as, how do you ensure that underlying directories will not have files with same name? And if they do, which one will be visible? What do you do when a file is deleted? etc).
Yes, if cosource was alive, I might've done it through them.
On other hand, I don't feel that I need a mediator between me and developer[s]. Yes, in direct contract between me and developer, there's slightly more risk of non-payment or non-delivery, however, that risk will be limited by clearly marked milestones.
Addition:
l is t_16Nov01.pdf
Patents
Yes, this is an issue. No, I don't have commercial backing.
The full list of patents claimed by various companies in relation with ITU recommendations is here:
http://www.itu.int/ITU-T/dbase/patent/files/Pat
No, ITU does not have 'essential patent' list for any of modem algorithms. Yes, there are companies that claim to have patents related to implementation of v.34 and v.90 (13 patents for v.34 and 26 for v.90). I'm investigating which precisely patents are these (some of them have patent numbers, some don't).
I'm still researching this issue...
Hardware interfacing:
Yes, this is separate from the project. Hardware is abstracted by "offhook/onhook, read/write PCM data", to simplify the development.
Drivers for specific hardware will be written later.
Jamie, first I have to thank you for this very informative post which clarifies for slashdot crowd many issues involved.
Re: Working on the code
Yes, I obviously know about your work and mentioned it as one of possible bases to start off development, and I also know that it has been progressing slowly. If the bounty causes you to spend bit more time on the code (and join a team who'll do certain other pieces), that'd be the best possible outcome.
Re: Homologation
This is a tricky thing. Yes, you are right, legally, both hardware and software (in case of soft modem) must be certified for connection to phone system. I've been thinking how to handle this (as I definitely won't be able to fund certification of each individual hardware piece+software piece), however, I don't have clear handle on it.
Hopefully, individual modem manufacturers will be receptive to the idea "How about you make your modem accessable to 10 more million people at an expense of (whatever part 68 certification costs)", at no risk to your intellectual property.
I'm not even sure how (or whether?) do they certify each new revision of WinModem software. Is only software certified? (not likely!).
Is each combo of hardware+software certified (expensive!). Do manufacturers certify one version only? (most likely).
I'm going to find out, hopefully FCC will be receptive. If the latter is the case, that's the strategy we'll pursue.
Yes, I don't expect to find someone in US who will try for the bounty. I expect a few people in developing countries to go for it.
The project will take anywhere from 6 man-months to 12 man-months by my estimates.
The DSP that is in the modem will _not_ be used for the purposes of this project. Thus, we can abstract from modem hardware on the level of "Read/write PCM data, take offhook/onhook". (very simple API). Even dialing falls under generation of PCM samples.
Well, I said "background". This does not mean "10 college-level courses and 5 years of experience".
Background merely means you should already have done a project involving digital signal processing. This may range from developing software Caller*ID device (FSK demod) to someone who developed ADSL hardware.
Yes, that's correct (no use of DSP will be done). The reason behind it is to simplify the work, and to avoid getting into details of each individual DSP's assembly/programming.
Hardware-specific code is actually out there for many devices. At any case, reverse-engineering of each piece of hardware can be done later once this is completed.
No, I am not related to any manufacturer of any winmodem-related device.
No, this has absolutely nothing to do with Lazard. I'm a mere IT consultant there, and they know nothing about this.
The money involved is my savings, that's it.
Uh sorry, that ain't me, there's another person
with same name (my distant relative).
Sorry, to clarify: This particular restriction is to make sure the code will be developed in foreseeable future.
This is not a toy project. The knowledge needed to complete it is significant. I wouldn't expect someone who already HAD implemented a modem, but I expect someone who knows what signal processing is all about.
I'm sure that Linus had some knowledge of OS concepts when he started writing Linux, by that, I mean knowledge of things like design of scheduler, message passing, etc, etc.
In the same way, I expect that people who would develop this code would have knowledge of filter design (FIR, etc), and
Yes, you are absolutely right, and I actually clarified this fact later on the list.
I'll take care of certification and fees involved, but the modem developed for this bounty has to be certifiable.
To my knowledge, there are no patents that would hinder this particular development.
Notwithstanding this, there ARE patents in the general area:
SMLink has bunch of patents, but they are all (again, to my knowledge) in hardware-chipset area, not in driver area.
PCTel also has patents in the same area.
Rockwell and Agere have patents in DSP-modem area.
There are patents for the algorithms involved in v.34 and v.90, however, I believe they all can be either avoided (by implementing differently), or denied by presenting prior art, however, they are the biggest threat.
These patents are owned by PCTel and SMLink. I'm still in process how to avoid them.
As a matter of fact, there was a ternary computer built in Russia, called Setun' (apostrophe signifies a soft n).
Russian translation of Knuth's Volume 2 was quite funny. Knuth is saying that "Somewhere, some strange person might actually build a ternary computer". The russian translation had a translators footnote "Actually, it has been built in russia in 1960s".
See this page for more information about setun:
http://www.computer-museum.ru/english/setun.htm
This scheme sounds strangely too familiar to
. html
VMSK. (a fraud perpetrated by Hal Walker).
There's an excellent treatment of it by Phil Karn (of KA9Q fame) at http://people.qualcomm.com/karn/papers/vmsk/index
Multiple reasons:
a) DSLreports information can be wrong. Many providers advertise 'we can get DSL to anything' while they can't do it really.
b) It could be that actually BA doesn't have their DSLAMs in the CO, but other CLECs do. Then you are in luck.
But at any case, if you are too far from CO, you will not be able to get DSL through anyone.
Actually you can't just switch, since Covad and Concentric use completely different modulation (SDSL modulation, even when the service is claimed to be "ADSL". Its actually a capped SDSL)
This is called "ingress filtering" and has been advocated in IETF workgroups and on NANOG for last 3 years.
;)
See following RFCs:
http://www.faqs.org/rfcs/rfc2267.html ('98)
http://www.faqs.org/rfcs/rfc2827.html ('00)
Many 'big' ISPs apply that to their leaf connections at the edge routers, smaller ISPs usually don't do that, which is surprising since its actually simpler to do if you are small. (less edge routers
The only problem with such filtering are people who are dual-homed and have asymmetric routing: I.E. Customer has to connections, to ISPs A and B, and may be sending outbound traffic with source-addresses in B through A's connection.
This is legitimate, there are many uses for it:
1. Satellite one-way connections
2. 'overflow' routing
3. load-balancing of outbound traffic
So, ISP has to blow holes in their filters for such customers. (Which we do at customer request).
Swap is never really reused anyway. Swap is encrypted to protect from stolen-harddrive-attack.
No. Do basic math: Swapping means at least 5 ms delay to throw data to disk, which is about as slow as anything can get. In these 5ms, you can encrypt quite a lot of data even with something as slow as DES. Blowfish would be blazingly fast.
In short: Encryption performance is about as fast as drive I/O, and initial delay on IO makes it unnoticeable.
1. Theo's beef is with NetBSD, not FreeBSD.
2. If you don't wanna pay 25$ (miniscule), download it. Periodic CVS updates are recommended.
Ok, so I skipped a bit of complexity. :)
It can be done both ways, split it at the MDF, or split it at DSLAM. Usually its done at DSLAM.
If the signal is going to CLEC, it doesn't go to ILEC switch, its done at the MDF.
MDF is a huge room with, on one end, strands of copper coming in from the street, and on other end, aggregated copper going to CO switches.
(Think: Patch Panel x 1000)