From bmanning@ISI.EDU Tue Aug 30 11:08:01 1994 Subject: Re: Comments To: ltwu@faline.bellcore.com (Liang T. Wu)
Thank you for your insightful comments. I would like to be enlightened on exactly how a proposed migration from RFC1490 to RFC1483/1577 will occur. As I understand it, there needs to be a translation method between NLPID and LLC/SNAP. There seem to be other locations in the stack where translation must occur. Is there capability today or even planned that will do these translations?
I understand Cascade claims to have such boxes.
There is no clear migration path from this approach to a more correct/robust implementation using RFC 1577 encapsulation over native ATM (OC3c).
My conversation with Cisco indicates that 1490/AAL5 software patch for AIP is available and 1483/AAL5 for ADSU and 1483/AAL5 for T3-AIP should be available withing about 6 months. So, indeed ther are several migration path available, not clear which is the best for all NAPs. Perhaps different NAP location may have different business needs based on what their customers desire.
True.
There are additional points of failure and additional costs with the requirement for an ADSU.
I think HSSI is a proven technology. HSSI/ADSU probably has lower failure rate than AIP based on the typical bath tub curb for new product reliablity.
The points of failure are the additional cables and connectors, not to mention the electrionics of a seperate box (the ADSU) and power. These cost, plus the extra rack space and potential co-location fees to accomodate this extra gear. Your concerns wrt infant mortality on new hardware seem to apply to the ATM switches in general. Most of the equipment, while being "long in the tooth" as far as cell switching capability is concerned, has a -very- limited exposure to data transmission. Even the closed ATM Forum has trouble standardizing specs that appear to be needed to support full interoperability (just when will UNI3.1 come out and when will the text be available on-line?... but I digress)
We need to separate out issues regarding ATM switches and ATM interfaces for routers. We have been dealing with ATM switches since 1982, at that time we call it Fast Packet Switch. So, we know much more about it and have trained scores of experts to deal with it. The commercial grade ATM switch that we are dealing with now for NAP are designed based on CO requirement, meaning it is overbuild and modularized based on certain engineering practice and has been tested extensively by telcos. The biggest issue now is to regineering the equipment for AAL5 type traffic since most of the switches were designed for "isochronous" traffic at the beginning. Router interface is another story. They are new and they interface with heterogenous network world. So, new rules have to be established jointly by data networking and telecomm communities.
The listed approach requires manual configuration.
I like the flexibility of AIP, but how to configure AIP to avoid congestion is still a research topic for me.
As it is for everyone. The manual configuration specified here is the need to code static routes and ARP entries to make BGP4 work. Traffic shaping does not even come into this equation.
We/NAP people are knowledgeable on "layer 2" and are eager to learn about the layer 3 problems. We like to help if we can. Let me know how can we get involved with the BGP4 development from layer 2 point of view.
This appears to lock the NAP into a top speed of 45Mbps or DS3 speeds.
Hopefully, we can unlock this as soon as we feel comfortable with other approaches.
HISSI at faster than 45Meg? I am very interested. Please tell me more.
I did not mean that. But HISSI at SONET rate may have some nich in the market. It is a marketing decision for router guys.
BTW, I think the Merit paper is useful and good work as you said. Since RFC1490 is the only viable option exposed to Merit, saying it is one of those is a bit too harsh.
Perhaps. My biggest concern was that the Merit paper would be construed as the -only- way an ATM NAP would work. They clearly did not indicate there were potential choices nor did they indicate the assumptions that were made for their test.
-- --bill