RE: ATM SVCs/Signalling

["Mark Borchers" <mborchers () igillc com>]

Will go off list with any subsquent Q&A, but here is the
further detail on the architecture:

> 1. What manufacturer of the devices and what model are the edge and then 
> the network device you are connecting to?

Using Marconi 200ASX connecting to transit provider's Fore/Marconi
switch (don't know their model).
 
> 2. What version and revision of UNI (3.1,4.0) is your edge device using? 
>  UNI 3.0 is PVC, UNI 3.1 is original SVC support, UNI 4.0, 4.1 if it is 
> out yet is more advnaced SVC. PNNI 0 did not support SVC so
>       that would need to be at least PNNI 1.0 as I remember.

UNI 3.1

> 3. What version of NNI / UNI are the Network devices using?

I'm signalling IISP to the far end.  Our network is very simple and
IISP meets the requirements.  Besides, I don't know PNNI and the
project schedule probably doesn't permit time to learn it.
 
> 4. What error code return are you getting?

I've seen both UNI error code 3 and 35.

> 5. Are your NSAPI addresses statis or dynamic and do you have dynamic 
> TEI registration set or are they statucally assigned.

Static.  If by dynamic TEI registration, you mean ILMI, we're
configuring ESI on the routers and registering with the ASX by 
ILMI.  Does that answer the question properly?

> If your NSAPI and TEI are dynamic and your keep alives are not set rigth 
> perodically you will drop "unregister" the NSAPI / TEI amd it will have 
> to be reregistered again and
> during this time the "route" would be dropped.

Thanks!

Mark


> John (I Still Do Not know) Lee
>
> Mark Borchers wrote:
>
> > Good morning,
> > I'm working on a project that requires the use
> > of ATM SVCs through a large PNNI cloud.  My equipment
> > sits on the edges of the cloud.  It appears that static
> > NSAP routes configured on one of the upstream edge
> > switches is being intermittently withdrawn (or blocked).
> >
> > Are there any operators on the list who have experienced
> > this type of problem or could point me in the right
> > direction as to what could cause this to happen?
> >
> > Thank you,
> >
> > --
> > Mark Borchers
> > Infinite Global Infrastructures, LLC
> >
> >
> >