Subject: RE: RFC2514 v1.1

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Tue, 19 Oct 1999 14:39:04 -0400

>  >Interconnection with a frame relay endpoint requires a different
>  >cross-connect table than that used by ATM SPVCs or PVCs.  
> That makes the
>  >FR/ATM IWF a different kind of PVC endpoint and the use of 
> the AtmConnKind
>  >is appropriate to make that distinction.
> 
> ^^ Not at all. Within an ATM switch, there still can be 
>      a standard ATM cross-connect (there is in our switch). 
>      There is another separate cross-connection that
>      is required to correlate ATM with Frame relay. The two
>      are distinct. 

Interesting!  Cross-connects to cross-connect the cross-connects!  But this
capability is not described in the ATM MIB.

The proposed AtmConnKind mechanism is simple and works within the current
model of the ATM MIB.  Interesting extensions for greater cross-connect
flexibility should be explored in future I-Ds.

>  And in a host environment, I similarly see
>      no reason to limit the IWF to use only PVCs (not SVCs).

The IWF is defined {{ONLY}} for PVCs.  Work on an SVC IWF is in progress.

Ken

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Tue, 19 Oct 1999 11:58:31 -0700

Ken,

 >From: "Rehbehn, Kenneth" <[email-masked]>
 >To: "'Michael H. Grobelch'" <[email-masked]>
 >Cc: [email-masked]
 >Subject: RE: RFC2514 v1.1 
 >Date: Tue, 19 Oct 1999 14:39:04 -0400
 >

^^ I believe that's the part an FR/ATM IWF MIB needs to add. In an ATM 
     switch with a line card supporting FR/ATM interworking, the line card 
     performs interworking, and the switch routes the cells between an
     external port/VPI/VCI and an internal port/VPI/VCI as for any other ATM 
     connection. There should be an ATM cross-connect for such a 
     connection. Otherwise, you would lose a great deal of information on the
     behavior of the system.

     At the edges, other cross-connect data structures would be needed
     for the ATM/Frame-Relay cross-connect. Perhaps add  a cross-connect
     index for something like the atmVclFrameRelayIwfTable I mentioned,
     for the ATM->FR direction?

 >flexibility should be explored in future I-Ds.

^^ It confuses the user and the kind of the VC.

 >The IWF is defined {{ONLY}} for PVCs.  Work on an SVC IWF is in progress.

^^ Our product offers Soft PVCs today.  The Frame Relay
     Forum indicates SVC support is planned. And adding further to
     these enumerations to have PVC/SVC/Soft PVC codepoints seems
     to me to demonstrate the orthogonality of the concepts.

Mike