North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
- From: bmanning
- Date: Tue Aug 30 11:07:38 1994
- Posted-date: Tue, 30 Aug 1994 08:07:28 -0700 (PDT)
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?
> > 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
> > 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
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)
> > 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.
> > 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
HISSI at faster than 45Meg? I am very interested.
Please tell me more.
> 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.
- - - - - - - - - - - - - - - - -