From owner-freebsd-isp Wed May 30 14:32:47 2001 Delivered-To: freebsd-isp@freebsd.org Received: from aries.ai.net (aries.ai.net [205.134.163.4]) by hub.freebsd.org (Postfix) with ESMTP id EAACF37B422 for ; Wed, 30 May 2001 14:32:36 -0700 (PDT) (envelope-from deepak@ai.net) Received: from blood (adsl-138-88-49-91.bellatlantic.net [138.88.49.91]) by aries.ai.net (8.9.3/8.9.3) with SMTP id RAA29422; Wed, 30 May 2001 17:32:15 -0400 (EDT) (envelope-from deepak@ai.net) Reply-To: From: "Deepak Jain" To: "Tom Samplonius" , Cc: "Laurence Berland" , "Colin Campbell" , "Christophe Prevotaux" , Subject: RE: OC48 interface Date: Wed, 30 May 2001 17:36:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----Original Message----- From: Tom Samplonius [mailto:tom@sdf.com] Sent: Wednesday, May 30, 2001 1:22 AM To: bv@wjv.com Cc: Laurence Berland; Colin Campbell; Christophe Prevotaux; deepak@ai.net; isp@FreeBSD.ORG Subject: Re: OC48 interface On Wed, 30 May 2001, Bill Vermillion wrote: > > > I'm still learning all this too but from what I've read the opinions > > > are the OC-768 won't happen because SONET is a TDM [Time Division > > > Multiplexing] method and carries a lot of overhead with it. > > > AFAIK TDM isn't frowned upon all that much. It carries overhead > > as far as someone needing to provide clock, but it seems like the > > best way to make truly separate channels in the same band on the > > same fibre/pair/transmitter area. Or CDM, I suppose. Ethernetish > > technologies are better, IMHO, for things where you just want a > > big fat pipe. I guess this is why bandwidth ppl like it, but for > > traditional telco stuff you might want sonet. > > Absolutely - but we have the 'circuit switched' tradition in telco. > A certain cell is associated with a certain link. The electrical > equivalnet of pictures form the early days of telco with poles with > dozens of cross-bars and hundreds of wires. Separate channels is > indeed a ciruit switched philophy. But the world is moving rapidly > to packet-switch, but telcos have a lot of SONET infrastructure. Telcos want to move to packet switching, because they want to oversubscribe the network capacity. At the end of the day, many people want guarrenteed dedicated bandwidth. I see the use of SONET increasing. --- The theory of telco-style multiplexing (simplified) is the following. I can sell 2000 1mb/s pipes and have 700 mb/s of capacity and NEVER deny any packet to anyone. This means no increased latency and no packet drops. The ISP-style of multiplexing (aka oversubscribing) is similar to the following. I will sell 20 1mb/s pipes when I have 10mb/s of capacity. The problem is that usage patterns don't become statistically predictable below a certain point and therefore while the ISP is sold at only 50% of capacity, he may be at 90+% utilization all the time. In the telco model, its almost never that way. Until you throw data sessions in. Then usage patterns grow. Multiplexing is still beneficial for end-user traffic, but generally not on core<>core traffic. --- POS (packet over sonet) links are more and more common on the various backbone providers. Basically POS is PPP over Sonet. SONET is much simpler than ethernet, so it requires PPP for IP encapsulation. The efficiency of such links is very high. Much better than ATM. --- SONET is a physical layer protocol that (when implemented) can provide switching around cut fiber in sub milliseconds. There is no such thing as native IP over Fiber, but POSIP is the closet thing we have. IP has no extension that can tell you if a link is up or not. -- ... > > > It makes sense. I know that were I have some machines located [in > > > a Level 3 facility] they say their goal is to drop all SONET and > > > become a pure IP transport. > > > I assume by IP u mean ethernet or some similar technology with IP > > running on it, or am I being dense again. > > I'm assuming a lot will be ATM. Ethernot has a lot of overhead > too. I'm just getting my feet wet there, and I've got a DSL link > coming up next week - and it's ATM. PPoA. If it were PPoE you'd > enacapsulate the Ethernet in the ATM and do the reverse at the far > end. Native mode makes more sens. ATM has tons of overhead. About 10 to 15% usually. Ethernet is pretty light in comparision. PPP is basically nothing in comparison. Long haul links are expensive, and most backbones are switching to POS. ATM is disappearing on many backbone networks. Some backbone providers (ie. Teleglobe) refuses to put any IP over ATM. ATM is in significant decline. I'm aware of some regional IP providers who are phasing out all ATM links in favour of PPP links (POS, DS3, etc.). All the OC192 router interfaces that Cisco and Juniper make today are POS, not ATM. I'm sure that Cisco and Juniper are going to be all over OC768 POS too. ATM makes sense for DSL, because usually people want DSLAMs to be simple, so they make the ATM network do the work. I've worked on direct bridged DSL (ethernet over ATM) and PPPoE (PPP over ethernet over ATM) network. The biggest problem with DSL is not the bandwidth, but getting the DSLAM traffic to the IP network. Paying another 5% overhead seems small in comparsion to how difficult your ILEC/CLEC might make this for you. Tom --- Keep in mind that ATM is very good with multiplexing and QoS because it has a very high IP overhead (~30% in the real-IP world). Since you are definitely oversubscribing in a DSLAM case, this helps make sure everyone gets enough bandwidth to be happy, and the heaviest users get curbed the most when needed. ATM connections have other advantages like having a cell cloud where you can have multiple DSLAMs in multiple cities and connect to that cloud via a single entrance per ISP. If a single company were doing all the DSLAMs the cost would be no better than a single point-to-point from each CO to the datacenter. Since multiple ISPs provide DSL service to the same set of DSLAMs, its either FR or ATM, and FR is generally provided over ATM anyway nowadays. Deepak Jain AiNET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message