Date: Mon, 3 Aug 1998 11:02:33 +0900 Then my question is: why 155M ATM interface is easier to make than 155M POS interface?

As folks have already mentioned, it isn't. However, for economies of purchasing, at least one vendor is using the same chip, and bypassing the ATM part.

Although the net capacity of 155M ATM is less than 155m POS, their capacity for IP packet is really close. I think its nearly the same challenge to pump up a 155M ATM pipe as a 155M POS pipe with IP packet for a router.

It is actually _much_ easier to pump a 155Mbps POS pipe. The first one was a simple graduate student project! Anyway, to fill you in on a bit of the history: ATM was presented to the IETF by George Clapp of Ameritech in November of 1991. This was the same fellow chairing the IP over Large Public Data Networks Working Group. (You remember X.25?) Bob Hinden (then of BBN) lead a short meeting on IP over ATM. Several of us in the back of the room got together, saying this is much too complicated, there has to be a better way. There was a bit of discussion over on the end-to-end-interest list. Craig Partridge wanted a simple PPP-like encapsulation. And so, it fell to me, the Editor of the PPP WG, to study SONET and SDH and their differences (at least 3 months of unpaid work), buying books and specifications, talking to folks at Bellcore, BBN, etc., and come up with something simpler. Which was completed mid-1992. A prototype was built at SUNY Buffalo. Unfortunately, the IESG member (Steve Knowles) responsible for the PPP WG thought nobody would ever build PPP Over SONET commercially, because ATM was the next big thing. And George Clapp and others in IPLPDN were adamantly opposed to the PPP WG covering something they considered their turf ("large public data networks". So, we were restricted to a design for short-haul private networks. And the IETF standards process was in flux, so we didn't know whether to publish as Experimental or Proposed Standard. These political problems delayed publication until 1994. Finally, a commercial vendor (NetStar) decided that they could build it. And Cisco got wind of the project. Cisco hates to be second to market, so they quickly came out with their own, beating NetStar by a few weeks. Unfortunately, we've since learned a few things. Features that work fine in a private network fail with the large carrier networks. For example, a widely deployed ATT/Lucent chip has a 200 millisecond DC bias. This blatantly fails to meet both SONET and SDH clock recovery requirements, but is good enough for voice. There were also some other problems with Cisco's quick project. But, the folks there did the honorable thing (how rare) and offered a free replacement for all their fielded boards! Last Fall, the large carriers were up in arms about the DC bias problem; and unlike Cisco, would not replace their bad boards. They insist that we change, instead. It turns out that it doesn't matter much to us, as it never happens by accident. Even when directly induced (the killer packet), it only happens about 1 out of 2,000 packets. Compared to MAE-East, this is nothing.... With a heterogeneous mix of traffic, it would never be noticed. I've put together a compendium of the problems encountered in large carriers, and proposed solutions. I just split it into 3 related internet-drafts last week, and they should be up on the net whenever the busy drafts person gets them posted, probably by the end of the week. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32