Re: Cable Modem [really more about PPPoE]
At 12:21 PM 6/26/01, Steve Schaefer wrote:
On Tue, 26 Jun 2001, Fletcher E Kittredge wrote:
On Tue, 26 Jun 2001 10:28:16 -0400 (EDT) Chris White wrote:
DHCP alone is not a viable option in this model. How do you get the end user traffic to the ISP and back in a pure IP environment? Policy
routing,
GRE, MPLS, force your ISP customer to interconnect at every location, etc.?
Hello Chris;
You provide frustrating few details and a statement "DHCP alone is not a viable option in this model." Could you restate more concretely what is your design problem which can only be solved by ATM/MPLS/PPPoE? I hesitate to answer for fear that there is some constraint I don't know about.
The constraint is that outbound packets need to go to the right ISP. That is, the packets need to go through the carrier network according to the business relationship, not according to the destination IP address.
This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet sells services to LOTS of ISPs from all of its POPs. The RADIUS authentication has to get to the proper ISP, but the traffic certainly does NOT travel to the ISP's network before going out into the world. Traceroutes from your dialup account will show that the traffic goes directly. UUNet charges the ISP a fee for the use of the dialup, and UUNet provides a relaying of the RADIUS traffic to the right ISP, and provides transport for the end user's packets. The same scenario COULD be used in DSL or cable setups. That's not to say that it will be.
Some method of identifying the ISP associated with each outbound packet is necessary. Policy routing, tunnels and PVC's are a few methods. VLAN tagging works, too.
Right. Assuming the business model where the ISP actually handles the traffic. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
On Tue, Jun 26, 2001 at 12:40:54PM -0400, Daniel Senie wrote: [..]
This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet sells services to LOTS of ISPs from all of its POPs. The RADIUS authentication has to get to the proper ISP, but the traffic certainly does NOT travel to the ISP's network before going out into the world. Traceroutes from your dialup account will show that the traffic goes directly. UUNet charges the ISP a fee for the use of the dialup, and UUNet provides a relaying of the RADIUS traffic to the right ISP, and provides transport for the end user's packets.
.. which btw could be anything. Could be proxy RADIUS or proxy DHCP or whatever.
The same scenario COULD be used in DSL or cable setups. That's not to say that it will be.
If I may add my $.02... I think you hit the nail right on the head. And cost pressure is what *may* change that COULD to a WILL. (Seems things have to get a lot worse before they will get really better). Seems that the model works for dial because nobody has any ill conceived notions about needing to 'own' the last mile like connection to the subscriber to offer value add services. For two reasons: a) people have realized that there really isn't much value in owning dial POPs anymore and b) it's difficult to add much of any value add services to the link itself because of the limited bandwidth. This notion of selling value add services and 'owning' the subscriber is something very commonly found in broadband networks. Sure, you could send broadcast quality TV down a DSL pipe, but who's actually doing this as a generally available service? Dial appears to be such a low end commodity that people have given up on that type of model, and just want to get folks on the net with a certain quality of access but that's about it. Isn't that the one thing what most if not all DSL and cable lines achieve? Seems to me that there's too much marketecture driving these deployments, and that the rent-a-POP model could drive cost down considerably. Which would mean that all of us would be better off for it. Those who object to rent-a-POP models typically are the same that think # of hops matters vs actual latency/quality of service/access and believe that video etc services must always be supplied locally to be working properly. Again, clueless marketecture methinks. I don't claim to have a solution, I just find it interesting that there appears to be a fairly narrow horizon in this area, when it has clearly been proven that folks are willing to live with the other model just fine. The rent-a-POP model's sole weakness is an organization's inability to work out a proper business model... Now, what does all this have to do with DHCP or RADIUS? Well, in the rent-a-POP model, nobody cares how the actual authentication and accounting is done as long as it is accurate and fits the billing system needs of the wholesale customer. Whatever works, is relative to the other options cheapest and most reliable (offering the greatest economies of scale) is the one that's chosen... Do I carry a religion either way? Not really. Seems that DHCP & DynDNS integration is more readily available than RADIUS & DynDNS... But that's just my opinion and not a representative survey. Cheers, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only.""
On Tue, 26 Jun 2001, Daniel Senie wrote:
At 12:21 PM 6/26/01, Steve Schaefer wrote:
The constraint is that outbound packets need to go to the right ISP. That is, the packets need to go through the carrier network according to the business relationship, not according to the destination IP address.
This isn't necessarily the case. Take a look at rent-a-POP dialups. UUNet sells services to LOTS of ISPs from all of its POPs. The RADIUS authentication has to get to the proper ISP, but the traffic certainly does NOT travel to the ISP's network before going out into the world.
Well, are we talking about carrier transport or a wholesale Internet access? For UUNet to do this is a perfectly acceptable business relationship. For SBC to do this is a big no-no.
The same scenario COULD be used in DSL or cable setups. That's not to say that it will be.
I suppose an unregulated DSL provider could do this. However, I would not assume that even the DSL CLECs would be permitted, so I'm not sure such an animal exists. In any case, I know that this was _not_ what our customers wanted when I was working for a DSL CLEC. They represented their business access products on the strength of their transit arrangements and support. Now, if we're talking about purely residential services, it's potentially a different ball game. Price and ease of use are king -- more so than redundancy and consistent performance. Cable providers act as ISPs. If they offer wholesale Internet access, rather than carrier transport, then they can run their networks like UUNet dial POPs. I think most of them still offer neither... -Steve
participants (3)
-
Christian Kuhtz
-
Daniel Senie
-
Steve Schaefer